Changelog
* api-requests are now stored in database
* multiple entities are now possible (mapping per api-request)
* api-requests can be scheduled with a refreshLifeTime

Update notes:
* backup your hydra.yml
* remove api_requests from virtual_identity_twitter configuration in hydra.yml
* remove social_entity_class from virtual_identity_twitter configuration in hydra.yml (if used)
* update your datbase using doctrine:schema:update --force
* migrate your requests from hydra.yml to the database (directly insert them into the db or use the fancy ui)
* correct the TweetEntity-table - enter a valid requestId for all entries
* entities implementing the TwitterEntityInterface must implement two new methods (getRequestId, setRequestId)

New usage notes:
* command changed: hydra:twitter:sync [requestId] - you can optionally specify which request you want to execute refreshLifeTime is ignored in this case
* getFeed accepts an additional parameter array<string:requestIds> - you can specify which entities are fetched by requestid
* setApproved requires a new parameter requestId (otherwise we would not know which table should be updated)
* an additional getApiRequests method is available on the virtual_identity_twitter service
* syncDatabase accepts an additional parameter array<string:requestIds> - you can specify which api-request-results are synced
* you can moderate per request in the fancy user interface
* if you check the "Use since_id" checkbox, the system automatically adds the since_id as parameter. The max_id is stored by request.

Known issues:
* design has not been adopted correctly. the subform for the requests should use twitter bootstrap, not directly css
* when (dis)approving an entity from the "All" page the moderation view jumps to the connected request-moderation page