Proof of concept for a kernel with config/environment loader and service container in front/backend

# New bootstrapping in Fork

I tried to follow Symfony's way of handling things as good as possible (to save us work later on), and started work from @jelmersnoeck's HttpKernelInterface implementation. This PR works with a fresh 3.4.3 install from scratch.

Keep in mind that all this is conceptual.

## What is in this PR?
### New Symfony components through Composer:
- DependencyInjection
- HttpKernel
- Config
- Yaml

### File structure
An app/ folder was made to comply with Symfony's core structure. The Front controller is located in app/bootstrap.php for now. It gets required by several files in Fork (index.php, ajax.php,...). Some files have camelcased filenames to match the PSR2-formatted Symfony files they are based on.

### What does it do?
The front controller creates a new Request object based on $_SERVER globals. AppKernel intercepts the Request object through the handle() method so we can load all Fork functionality first through the ApplicationRouting class. An instance of ApplicationRouting returns a handled Response object, which contains the processed HTML for the requested page.

Because AppKernel passes through Kernel, we can "inject" the kernel object and the service container into Fork.

This is pretty much how Symfony handles things. In Symfony it's not needed to pass the kernel object to its bundles, just the service container. There, Kernel is stored as a singleton in the service container.

## Service container
### What Symfony does
Kernel loads services via config.yml files (typically a global one + one for the active environment). It boots bundles in the Kernel and passes along the initialized service container to each bundle.

### What we do
We don't work with bundles yet, so I push the Kernel instance through to (Frontend|Backend)BaseObject via a KernelLoader class. The container is accessible through the Kernel instance.

The entirety of Fork (backend, frontend, cronjobs, API) is modified to make the new kernel + service container available everywhere.

```php
$container = $this->getContainer();
$kernel = $this->getKernel();
```
Additionally, I made the database object, fresh from the service container, available for actions in a shorter alias:
```php
// $this->getContainer()->get('database')->getRecords('...');
$this->getDB()->getRecords('...');
```

### Environments
AppKernel also accepts an environment and debug mode flag, just like Symfony: 
```
$kernel = new AppKernel('dev', true);
```
If set, it should load our environment configuration from a YAML-file in app/config/, just like in Symfony's core.
This system is implemented, but not used yet. We need to discuss how environments should be handled between now and the big switch to the Symfony core. Maybe we should not worry about this until we make the switch?

### Loader
With a place for services to be registered and our environment known, we are ready to load YAML configuration files that hold sensitive data and values for each environment. This should be done in registerContainerConfiguration. Underlying functionality is set in the Kernel class  to match the Symfony core.

### Models
FrontendModel/BackendModel no longer have a getDB(), but inherit from app/BaseModel, which uses the service container to create its database connection through a single getDB() method. This is intended as a temporary fix to not break Fork's models implementation.

In time, we want to move away from a collection of static methods here.

### Globals / YAML config
The Fork installer now writes globals data to app/config/parameters.yml (as well as keeping the existing library/globals.php file). The data from the config file is not used yet, except for the database data; the database service gets registered in the Kernel, with data from the YAML-file.