Making the new GroupContact pre and post hooks more logical (and less error prone)

I've started back at integrating Drupal organic groups with CRM, this time with 1.4 as the target version.

This is doable, but since I may be the only user of the code path so far, I strongly recommend changing the calling conventions of the new hook so that it is (1) more consistent with other uses of hook_civicrm_pre and hook_civicrm_post, and so that civicrm_pre can screen which ids are actually added or deleted from a group.

To see why the current situation is unsatisfatory, look at how the hook is called for an Individual or a Group.

First, look at the prototypes for the hooks (from CRM/Utils/Hooks.pre):
static function pre( $op, $objectName, $id, $params = null );
static function post( $op, $objectName, $objectId, &$objectRef );

I don't have a lot of examples of the pre hook. But for post:

Add a contact:
CRM_Utils_Hook::post( 'create', $params['contact_type'], $contact->id, $contact );

Delete a contact:
CRM_Utils_Hook::post( 'delete', $contactType, $contact->id, $contact );

Group is similar. But here's what you have now for GroupContacts:

Add a list of contacts to a group:
CRM_Utils_Hook::post( 'create', 'GroupContact', $contactIds, $groupId );

Remove a group of contacts from a Group:
CRM_Utils_Hook::post( 'edit', 'GroupContact', $contactIds, $groupId );

First, the order is just weird. Remember that the prototype of the Drupal hook is:
function hook_civicrm_post($op, $objectName, $objectId, &$objectRef);

So $objectId is going to be an array in this case, and $objectRef is an ID. Confusing. And it will
make for less readable code in the Drupal module, since it is going to be doing very different things with both $objectId and $objectRef depending upon context.

Second, 'edit' is only called for deletion. This is not what a module writer would expect either.

Certainly, documentation will help here, but I think it would be better if the call in this case were more in line with other uses of the hook.