[FEAT] Module initialization using lifecycle hooks

[Konstantinos Feretos]

Is your feature request related to a problem? Please describe.
Modules are currently written in a pretty chaotic way where initialization does not happen in an obvious or well defined order.

Describe the solution you'd like
Extend ConduitServiceModule with a class exposing lifecycle hooks for modules to use during initialization.
Said class should provide adequate options to cover any use case in regards to initialization order.

I can think of the following core initialization steps modules generally go through:

1. initialization (before registering with Core)
2. schema registration
3. activation

To cover any possible use case we should cover pre-target, target and post-target hooks for every(?) given step.
Example:

• pre_registerSchemas()
• registerSchemas()
• post_registerSchemas()

That way we get (optional) finer control over initialization while retaining the structure's self-descriptive nature.

While not strictly related to initialization, said class should probably also standardize configuration functions names (eg setConfig()).

[Konstantinos Feretos]

I should probably clarify pre/post-targets a bit further.
These are definitely not going to be abstract methods, therefore modules won't really need to implement these, as opposed to say activate() or initizialize() (which are already abstract in ConduitServiceModule).

When it comes to registerSchemas(), this technically isn't required as certain modules simply don't register any schemas, but we might wish to make it abstract anyway and just re-implement it as an empty block on these edge cases.