Fix regression, make sure if period is not supplied to ArchiveInvalidator then all periods are invalidated efficiently.

Do not perform an inner join on the archive table, for large tables this can make Piwik completely unresponsive and can result in invalidated archives never being purged.

Refs #7181, add logging to ArchivePurger service + archive purging scheduled tasks + Scheduler, modify CronArchive to run scheduled tasks within same process as core:archive so logs are visible in core:archive output.

Refs #7181, decouple invalidated archive purging from option table & site entity, no longer need to depend on option existing in order to successfully purge invalidated archives.

 This should not be necessary but we got several user reports that this was happening.

+ submodules

In Model use placeholders / bind parameters rather than writing the Id Sites in the SQL query - Models should be implemented in a safe way and not assume that the callee will have validated all against SQLI

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

refs #6508 Now we will purge only the right  monthly archive_numeric table and also only for the websites IDs that were invalidated

refs #6508 started refactoring the code, created two new objects: ArchiveInvalidator to include the API CoreAdminHome.invalidateArchivedReports and InvalidatedReports to store the info of which report was invalidated

This is only a start. Especially the Tracker model contains quite a bunch of different models. Ideally, one day, the tracker is refactored and all the goal tracker stuff including the queries are in the goal plugins, all the ecommerce stuff is in an ecommerce plugin etc. Haven't moved some of the LogAggregator queries.