Allow multiple component hooks for a given Component

[cBournhonesque]

What problem does this solve or what need does it fill?

It could be useful to have multiple component hooks for a given Component.
A usecase would be to allow libraries to create component-hooks that won't be overriden by the user.

For example, you could imagine bevy_ecs wanting to update change detection ticks via component hooks, while still allowing the user to define their own component hooks.

PROS:

• increased flexibility
  CONS:
• performance? we would have to store a Vec of hooks instead of just Option
• how to guarantee an ordering between the hooks?

What solution would you like?

Letting ComponentHooks store multiple hooks of a given type (on_add, on_remove, etc.) for a component.

What alternative(s) have you considered?

• Use observers? (not too familiar with them)
• do not allow multiple hooks

[alice-i-cecile]

Broadly in favor of this: I think that this is going to be a frustrating limitation for end users and third-party crate authors.

performance? we would have to store a Vec of hooks instead of just Option

We should use a SmallVec: I would expect one or two of these hooks at once usually.

[alice-i-cecile]

@maniwani explained the design intent to me on Discord. Users are intended to use observers (#12231) to cover this use case, while component hooks are left to only the most fundamental setup/cleanup operations for the type.

adding a component would run the "on add" hook before running matching "on add" observers and removing a component would run matching "on remove" observers before running the "on remove" hook