Pico now depends on Twig 2.12, Symfony YAML 3.4, Parsedown 1.7.4 and Parsedown Extra 0.8.1.

```
* [New] Kick-start development of Pico 3.0
* [Changed] Require PHP 7.0.8+
* [Changed] Update dependencies: Twig 2.12, Symfony YAML 3.4, Parsedown 1.7.4
            and Parsedown Extra 0.8.1; this is just an interim step, we'll
            update to Twig 3.0+ and Symfony YAML 5.0+ later
```

This commit includes no functional changes.

Pico now requires PHP 7.2.5+

Use AbstractPlugin::getPico() instead (e.g. `->getPico()->getConfig('my_config')` instead of `->getConfig('my_config')`).

Use Pico::getConfig('themes_url') instead.

Pico::VERSION_ID isn't updated because this is a alpha release.

```
* [Changed] Merge all fixes of Pico v2.1.2 to v2.1.4
* [Fixed] #575: Update Symfony YAML v3.4 to support PHP 8.0+
```

`%page_id%` is replaced by the page's ID, `%page_url%` by the page's relative URL, and `%page_path%` by the dirname of page file.

This reverts commit 812ae5c

…all()

This reverts commits efc4fb5 and bc816fe

This reverts commit ff5e345.

Runs `composer install` and `phpcs` on basically every push, replaces Travis CI.

Since Travis CI was transformed into a proprietary service we didn't have a CI pipeline. This heavily refactors and simplifies the CI pipeline and uses GitHub Actions to deploy new Pico releases. You can use Pico's Makefile to build new releases locally, too. Pico's build script no longer depends on any external resources (like our `picocms/ci-tools` collection). However, this isn't true for other release deployment steps, like updating phpDoc class docs, version badge, cloc stats, etc., even though the CI scripts are mostly self-containing now.

Mimics the behaviour of the 'deploy-release' workflow, even though branch deployment doesn't depend on Pico's tests to succeed. Pull requests still use the 'test' workflow directly.

…mespace

We can't enable strict typing everywhere without major BC breaks (likely Pico 4.0), so we're doing this on a best-effort basis.

Fixes #603

This is a workaround for meta pages (i.e. pages starting with a '_'): If a user attempts to request such a page, Pico won't respond with the contents of this meta page, but with a 404 page. This is expected behavior. However, we also have a shortcut in Pico::readPages() attempting to skip reading the contents of the requested page twice. Since we're not serving the contents of the meta page, but of the 404 page, we accidentally overwrite the contents of the meta page by Pico's 404 page. This is unexpected behavior. Even though this commit fixes this particular issue, it doesn't fix its major cause, as the shortcut still exists and can still be triggered by plugin authors by simply overwriting the contents of an existing page. Even though a plugin author might want this to happen, we can't really tell whether it is intended or not. The solution is to remove the shortcut, but we don't want that either, it's a useful performance optimization. The only real solution to this is to switch to page objects, allowing us to handle such situations more verbose. This feature is expected for Pico 4.0. For now we leave this partially fixed...

Fixes #602

Follow-up to 070714d

Since Pico depends on PicoDeprecated, and PicoDeprecated depends on Pico, a chicken-egg-problem arises: When pushing a new tag for Pico, GitHub Actions will try to build this new release by downloading the matching version of PicoDeprecated from Packagist. Since we didn't release a new version of PicoDeprecated yet, this will fail. So we need to push PicoDeprecated's tag first. Doing so yields GitHub Actions trying to build PicoDeprecated's new release - by trying to download the matching version of Pico from Packagist, which doesn't exist yet.

Thus builds will always fail - unless you push both tags at the exact same time, and unless you send some prayers that GitHub Actions delays building until Packagist picks up the new releases. The simplest solution is not to use GitHub Actions to publish new releases, but letting the user to do it instead. With this changeset this is as simple as `make publish version=v3.0.0`. The 'deploy-release' GitHub workflow now just updates the website and is triggered by publishing the GitHub release, not the tag. This additionally allows the user to perform some manual tests before publication.

The build script now depends on GitHub CLI (`gh`), see https://cli.github.com/. You must setup authentication first (`gh auth login`).

Fixes #623

see issue #671

replace strlen in readPages() with variables

* Added functionality for sorting pages by nested meta values.

* Additional variables removed.

* Added comment to the config template file about the possibility to access nested metadata with a dot as separator for sorting.

* Added entry in the changelog about the possibility to access nested metadata with a dot as separator for sorting.

* Changelog and config template adapted according to the suggestions.

* Added old entry back in the Config template.

fix Wrong config keys in discoverPageSiblings #675