[KeyManagement] Add KeyManagementBundle and register it in FrameworkBundle

The component ships its own bundle, the way every component the
FrameworkBundle used to wire now does, and FrameworkBundle registers it when
the package is installed. The configuration lives under the `key_management`
root key. Each entry of `clients` is a DSN, built through the factory
registry, and exposed both as a named service and as a named argument, with
the single client of a one-client application becoming the default without
having to say so; a bare DSN at the root is that single client.

Configuring `store` is what an application does to stop carrying a wrapped
data key in every payload, so the store-backed encrypter becomes what the
envelope interfaces resolve to. Nothing is lost by that: it is given the
default client's encrypter as a fallback, so it reads the payloads written
before it as well as the ones it writes. The per-client encrypters stay
reachable under their own name for whoever wants the other regime explicitly.

Each bridge factory is removed from the container when its package is absent,
and configuring a store without symfony/doctrine-dbal-key-management fails at
compile time with the command to run.

Autoconfiguration tags every blind index the application registers, and the
compiler pass of symfony/doctrine-orm-key-management hands them to the listener
filling the index columns, which is removed when there is none.

The four console commands are registered alongside when the Console component
is installed.

In debug mode, the data collector is registered and kept only when a profiler
collects it; a compiler pass then wraps every tagged client, its envelope
encrypter and the store in traceable decorators feeding
`KeyManagementDataCollector`, which aggregates what a request encrypted per
call site, per key and per service, and puts the counters on the toolbar. The
collector records byte counts, ids and durations, never payloads, AAD or key
material. The WebProfilerBundle panel renders those three views.