Add more docs for Feature Layer

not complete, but progress..

docs/features/people/entry/merging.rst

@@ -0,0 +1,44 @@
+
+Merging
+=======
+
+Rattail ostensibly supports merging any 2 records, of any kind.  But
+the devil is always in the details...
+
+In most cases a merge involves:
+
+* inspect differences between 2 records
+* choose which one to "keep" vs. "remove"
+* perform the merge, which:
+
+ * may *update* the "keep" record, with certain data from the "remove" record
+ * then *deletes* the "remove" record
+
+For some things this can be pretty straightforward, for instance if
+your User records are maintained only in Rattail and aren't imported
+from elsewhere, then a merge of 2 User records could by definition
+only affect Rattail anyway.
+
+Although even that example can be tricky, because a User is often
+involved in some audit trail(s) of various other data records.  In
+such cases Rattail can update the historical records to reflect the
+new "keep" User record; but in practice there may be edge cases as yet
+unexplored.
+
+Customer and Employee records etc. can present more of a challenge,
+because often that data lives in multiple systems.  The question
+becomes, what should a merge actually *do*, i.e. what should the
+ideal outcome be?
+
+In particular your POS may have 2 customer records which you'd like to
+merge, but even if your ideal outcome is for one of them to be deleted
+(i.e. typical use case described above), the problem of historical
+data may come up again.  Often times both of the customer records will
+already have accrued some transaction history within your POS, and it
+may not be possible or practical to correct those with the new
+("keep") customer reference.
+
+But the merge tool is meant to be as flexible as is reasonable.  Your
+merge logic might be able to go ahead with certain "simple" merges but
+then raise an error when complex situations are encountered.  Then you
+can look more closely at those and see what can be done (if anything).