As soon as a setting is used in tracker mode we will cache it now making it much
easier for developers to use settings in tracker mode and we will no longer
query the database on each tracking request if a setting is requested apart from
cache creation. Refactored the settings API under the hood to make this possible.
The classes were doing things they were not supposed to do. For instance settings
class also took care of storage which it should not and settings class took
care of many validation things that should be done in a setting class. I cleaned
up that code and it is also much better testable now.

Add unit tests for new Metrics Formatter classes and remove existing ones. Small change to Overlay included and bug fixes to metrics formatting code included.

Declares a process as finished as soon as a PID file is > 500bytes
(contains only PID) and output file is > 100MB (which should usually
not be larger than 100KB or 1MB) to prevent files growing up to many
GBs. I added unit and integration tests for the file size detection. It is
now possible to mock the methods file_exists and filesize although very
simple so far. Later we can allow to define callbacks or to define different
return values for different files or we can use something like vfsStream

The `tmp/` path was hardcoded everywhere, which resulted in using `SettingsPiwik::rewriteTmpPathWithInstanceId()` to rewrite it for specific use cases.

I've moved that path into the config, and replaced all hardcoded usage (and calls to `rewriteTmpPathWithInstanceId()`) by a `get()` from the container.

Getting entries from the container is a bad practice and dependency injection should be preferred, but we do baby steps. When refactoring those classes to DI, we'll replace calls to the container with proper dependency injection.
Another thing we'll need to do too is move the hardcoded *sub-path* of `tmp/` (e.g. `tmp/sessions/`) into the config also (but again: baby steps).

Another future step would be to remove completely instance ID and let it be handled by a plugin (or by end-user config). Having the `tmp/` path in the config means that plugins or users can override it and know it will be taken into account everywhere in Piwik.

refs #6417 this should fix some tests. Start initial value by 0 so first generated id will be 1

fix omnifixture creation was broken

refs #6417 wondering if omnifixture creation worked

refs #6417 acquire a lock per archive id which should be better

refs #6417 we have to generate the SQL in the update itself otherwise the update would fail at some point in the future if the tables signature changes

refs #6417 split updates into a separate update file otherwise it would not be executed for devs using Piwik from git

refs #6417 added some documentation

refs #6417 Piwik 2.9.0-b2 was released meaning we have to move it to b3

refs #6417 Piwik 2.9.0-b3 was released meaning we have to move it to b4

Fixes #6068, correctly decode JSON encoded ec_items query parameter values so escaped HTML is properly handled by tracker. Includes tests and a separate fix to tests:run command (command fails when --options is used w/ a group argument).

Extracted `Piwik::getJavascriptCode()` into a separate, non static class: `Piwik\Tracker\TrackerCodeGenerator`

`Piwik::getJavascriptCode()` is now deprecated in favor of the new class.