Do not use the old and undocumented TP-API anymore.

This prevents us from using any public Type/Subtype/Rarity IDs. We create our own, if we encounter a new type, but that means, we can't make sure, IDs are stable in dev environments. We should probably check in a SQL-File with "our" ID->Title tables.

 Disable instance pooling of Propel, because we will get memory problems otherwise...
Let puppet do the initial fill of the database

Puppet will now:
- import known types, sub-types and disciplines. That way we keep our IDs stable
- clear our caches and set the request slots up
- run tools/update-items-from-api.php to get the initial batch of items. Due to the amount of items, the provisioning will take quite some time and php will be swapping a lot in the end...
Updated the Readme to describe where to continue after a "vagrant up"
Added v2 Item API classes.

These classes are only slightly changed copies from the v1 API. Using the v2 API shortens the update-items-from-api.php by about a third.
Moved the item import to the v2 GW-API

This commit finishes the move to the v2/items-API of GW. We can now:
- nix the ItemDB-Queue (which happened, the workers will output a message and exit with code 1)
- use tools/update-items-from-api.php for item updates. The script runs about 5 minutes and creates new (Sub)Types if needed.

I also adapted the Readme.
Add the new ItemType "Back" to the priority system.

This is needed to be able to put the back items into the item listings queue.

More adaptions to the Readme and disable instance pooling for propel on importing the recipe map... That prevents swapping and makes the import faster by a HUGE amount.