While it does not make sense, it is possible to spawn activities with a
group_id set but without a grouping_metohd_id. This is for example easy to
trigger using recurseCallMethod from ERP5Type.Core.Folder: the
_recurseCallMethod activity spawned nullifies grouping_method_id but does
not (currently) clean group_id, leading to inconsistency between how
"non-groupped" conditions are evaluated in getProcessableMessageList and
dequeueMessage.
The consequence is zombie activities: they never fail, do not prevent other
activities from being executed, but and are permanently run on the node
which reserved more than one because:
- all but one activity is in MESSAGE_NOT_EXECUTED state, forcing an abort
- finalizeMessageExecution does not understand that MESSAGE_NOT_EXECUTED
  activities may not have failed, and itself fail while trying to detect
  the failure type (ConflictError vs. others), failing to free & postpone
  the activity, in turn failing to bring it to eventually permanent failure
  state.
Make those conditions consistent, and use tuple-unpacking to detect any
future inconsistency much earlier, simplifying debugging.