issue #24834, issue #24835 - don't grant privs to work around other problems

Shift focus from manipulating privs to relaying the data that actually changed from one object to another.

The old version of the crmacct 'after trigger' tried to grant privs to allow arbitrary users to synchronize `crmacct_name` and `crmacct_number` with the corresponding columns of other tables (e.g. `cust_name` and `cust_number`. The new version is more selective about when other tables get updated and lets their triggers control what's allowed and what isn't.

For users the result anticipated impact will be:

- Everyone who creates entities that are CRM Accounts (e.g. Customer, Vendor, Prospect) will need privs to maintain either his/her own or all CRM Accounts.
- Changes to Name and Number fields of these entities may need to be done by people with extended privs. For example, a person with Sales and CRM privs but no Purchase privs will not be able to change the Customer Number for a customer who is also a vendor. That kind of change will have to be made by a user with  `MaintainVendors` as well as CRM and Customer privs.