[RFR] VarDumper and DebugBundle

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | none
| License       | MIT
| Doc PR        | none

From a user land point of view, this PR creates a global `dump()` function that is to be used instead of `var_dump()`. The component can be used standalone in any dev workflow. Please see the [provided README](https://github.com/symfony/symfony/pull/10640/files?short_path=52d526f#diff-52d526f19bc9e3825c80e7694755409c) for details.

When used with the Framework bundle, variables passed to `dump()` are dumped in a new dedicated panel in the web toolbar. The function is also available in twig templates.

Regarding the implementation, I'm pretty sure you'll find a lot to comment. As I'm sure of nothing else, not even the names of things, please do.

I tried to organize this PR in several commits, from the most fundamental algorithm to pure Symfony glue.
I suggest you follow this order while progressing in the review and the discussion around this PR, so that we can together validate commits one after the other.

Don't hesitate to fork the PR and submit PR on it, I'll cherry-pick your patches.

TODO:
- [ ] open a doc PR
- [ ] open a PR on the Standard edition
- [ ] tests for the DebugBundle + other Symfony glue classes
- [x] inline css and js for compat with e.g. Silex
- [x] finish and merge nicolas-grekas/Patchwork-Dumper#5 for better UX
- [x] show a dump excerpt on hovering the icon in the toolbar
- [x] verify README and comments
- [x] validate interfaces/names (Caster / Cloner / Dumper)
- [x] validate new VarDumper component + DebugBundle
- [x] validate Resource/ext/ vs independent repos.
- [x] test and define behavior after KernelEvents::RESPONSE
- [x] update dependencies between components/bundles and composer.json files
- [x] no hard dep on iconv

Not for this PR but might be worth later:
- show a light stack trace + timing + memory at debug() calls
- create a "theme" concept for custom colors/UX

no ``else`` here as the ``if`` returns.

And what about using ``mb_convert_encoding`` when it is available and ``iconv`` is not ? It would be consistent with other parts of the system