[Intl] Integrated ICU data into Intl component #1

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #11447, #10807
| License       | MIT
| Doc PR        | -

This PR is an alternative implementation to #11884. It depends on ~~#11906~~ and ~~#11907~~ being merged first (~~these are included in the diff until after a merge+rebase~~ merged+rebased now).

With this PR, the ICU component becomes obsolete. The ICU data is bundled with Intl in two different formats: JSON and the binary ICU resource bundle format (version 2) readable by PHP's `\ResourceBundle` class. For a performance comparison between the two, see my [benchmark](/webmozart/json-res-benchmark).

~~The data is contained in two zip files: json.zip (2.6MB) and rb-v2.zip (3.8MB). The handler~~

```php
\Symfony\Component\Intl\Composer\ScriptHandler::decompressData()
```

~~needs to be added as Composer hook and decompresses the data after install/update.~~

The data is included as text/binary now. Git takes care of the compression.

Before this PR can be merged, I would like to find out what the performance difference between the two formats is in real applications. For that, I need benchmarks from some real-life applications which use ICU data - e.g. in forms (language drop-downs, country selectors etc.) - for both the JSON and the binary data. You can force either format to be used by hard-coding the return value of `Intl::detectDataFormat()` to `Intl::JSON` and `Intl::RB_V2` respectively. I'll also try to create some more realistic benchmarks.

If JSON is not significantly slower/takes up significantly more memory than the binary format, we can drop the binary format altogether.
Because these are insanely many tests (10000+) which take a lot of time to run (7 minutes on my machine). It's only necessary to run these tests when messing with the generator/provider classes and/or re-importing the data. Since nobody should be doing that except for a few core developers - who hopefully remember to run the tests ;) - it's better to keep the Travis build "fast, if you ask me.