Extensions declared in composer.json under extra.nette.di-extensions
are discovered from vendor/composer/installed.json and registered
automatically. Constructor arguments may use %parameter% placeholders.

Ordering and precedence: $defaultExtensions keep their hand-tuned
registration order and are registered first; discovered extensions
are appended after them, sorted alphabetically by name, because the
order in installed.json carries no meaning. Defaults take precedence
over discovered extensions of the same name.

This starts the gradual emptying of $defaultExtensions: decorator, di,
extensions, inject and search are no longer listed there because they
are discovered from nette/di metadata (a hard dependency, so always
present). Bootstrap's own constants and php extensions must stay for
now - the root package is not listed in installed.json.

excludeExtension() excludes given extensions from automatic
registration; without arguments no extensions are registered at all.
Exclusions are part of the container cache key.

- %parameters%
- three ... dots
- @inject & @var

enables first-class callable in 'create:'

Demonstrates multiple hooks within a single phase: static parameters,
dynamic parameters and dynamic validators are now generated by three
independent handlers running in declaration order.

Explicit ordering constraints replace the former hardcoded reordering
hacks in Compiler (InjectExtension moved last, SearchExtension inserted
before DecoratorExtension):

- SearchExtension: split into Register hook (directory scan) and
Discover hook (registration of classes not yet in the container)
- DecoratorExtension: Modify hook with before: InjectExtension
- InjectExtension: Modify hook with after: '*'
- DIExtension: Register/Modify/Compile hooks

Extensions can now register handlers for five semantic compilation
phases (Setup, Register, Discover, Modify, Compile) via the #[Hook]
attribute with declarative before/after ordering constraints:

- handlers are sorted topologically (Kahn), ties keep registration
order, so legacy extensions relying on registration order behave
exactly as before
- before/after targets are matched via is_a(), so subclasses match
- hook owner is tracked as extension instance, multiple instances
of the same class do not collide
- legacy loadConfiguration/beforeCompile/afterCompile methods are
mapped to Register/Modify/Compile phases and deprecated
- ParametersExtension, ExtensionsExtension and ServicesExtension
converted to hooks as the pipeline itself depends on them