Single invoke should merge results if multiple implementations for same module

Actually it is a bit more complicated.

If the hook implementations return something other than an array, then:

• core ->invoke() will return the literal value, e.g. "a".
• core ->invokeAll() will return a list of values, omitting NULL values, e.g. ["a", "b", "c"].
• hux ->invoke(), if more than one implementation, must still return a single non-array value. So it must discard other values.

If the hook implementations return arrays, then:

• core ->invoke() will return the literal array, e.g. ["a"].
• core ->invokeAll() will return the merged array, e.g. ["a", "b", "c"].
• hux ->invoke(), if more than one implementation, can return the merged array.

If implementations have different value types, it gets complicated.

Examples:

This is just one possible way to handle this.
Perhaps null values should _not_ be ignored?

Perhaps we should throw an exception if there are incompatible return types in the same module that would cause data loss.

Actually I like this as a general rule for all cases:

If multiple implementations exist in one module, they must each return array or null

This will only be thrown if invoke() is called, never on invokeAll().

h3. Backwards breaking changes
Projects or modules that newly add Hux won't have breaking changes, because without hux there can only be one implementation per module.

Projects or modules that already have multiple implementations with Hux could see a breaking change, but only if their previous implementation was ambiguous or relied on the overwriting.

Wow, I really need a better way to edit tables to insert here in raw html.
Some more variations and comparison with current version and core.

The MR contains different versions as separate commits.
We can pick and choose once we decide what we want.