Don't lower unregistered meta headers on the first level unsolicited (e.g. `SomeNotRegisteredKey: foobar` in the YAML Frontmatter should result in `['SomeNotRegisteredKey']`, not `['somenotregisteredkey']`). Furthermore, Pico no longer compares registered meta headers in a case-insensitive manner. However, you can now register multiple search strings that are used to find a registered meta header. This is achieved by flipping the meta headers array: Pico 2.0 uses the array key to search for a meta value and the array value to store the found meta value. Previously it was the other way round (what didn't make much sense...).
In the future we'll use picocms/pico-composer to create Pico's release packages (and picocms/pico-composer depends on picocms/pico-deprecated and picocms/pico-theme by default). Installing picocms/pico-deprecated and picocms/pico-theme is no longer required, but rather suggested. You simply don't need them in any case. You need picocms/pico-deprecated only if you're using old plugins, and picocms/pico-theme is obsolete when using a 3rd-party theme.
The performance vs. error-proneness trade-off doesn't justify this additional complexity. This is Pico 2.0, we always try to minimize BC-breaking changes, but we're breaking BC anyway by loading plugins from plugins/<plugin name>/<plugin name>.php only...
You can now explicitly specify both the `date_formatted` and `time` meta values to overwrite Pico's page date handling. Specifying `time` doesn't make much sense in general, however, specifying `date_formatted` allows you to use `{{ meta.date_formatted }}` on all systems, even those where `strftime()` doesn't work as wished
Due to the fact that Travis uses a shallow clone of Pico's Git repo, composer has no chance to detect on which branch it currently is. This was no big deal with Pico 1.0, however, Pico 2.0 depends on picocms/pico-deprecated and picocms/pico-theme. We use composer's `self.version` version constraint to sync the version numbers of these separate Git repos. Thus composer must know Pico's current version to resolve these dependencies. We try to guess the current version either using known branch aliases in Pico's `composer.json`, or using the `Pico::VERSION` constant (see `_build/install.sh`).
