refactor contacts info

After this refactoring we now offer 2 different ways to access contact data. You can either use the recommended
$ref entry and leave the interpretation of what happens with a specific link up to the platform you are on or you
can use the new value und protocol fields to get the "raw" data.

Reasons for favoring the first solution are things like tel: links just working on platforms like Android or
Windows/Lync. If you need to do data type things with the contacts (which is actually kinda discouraged) you
can use the raw data fields described above.

Please note that in the long run we will probably start expecting each platform to do the right thing when
it encounters an external resource while walking the API. We might add some kind of nofollow
information to links to ease the traversal to a newer API. I Don't expect this to get deprecated before we
hit 2.x so we will probably phase it out with 3.x at the earliest (if at all, who knows).
Merge branch 'feature/refactor-contacts' into develop
test for per_page param on collection

The tests for the new ``per_page`` param are being implemented in the /entity/country resource
since that resource was specifically created as a testbed for collections containing sereval
pages.
implement per_page request param

The per_page request param should now work on all collection resources. Paging through the results
is still possible by using the link headers since they also contain the pagination info.

I hope this can stay like it is, but we might need to re-add a server-side upper boundary check for the per_page
number. I'm leaving that open for the moment since it hasn't been decided where that boundary should be.
Merge branch 'feature/pagination-per-page-param' into develop
bump dependencies
refactor consultant loader for shorter method size
generated bundle for cache related things

This was generated with the code from the feature/generator-bundle branch and
only minor changes where needed before commiting.
implement etag and if-none-match listeners

For now using the sha1 sum of the response should suffice for our etag generation.

If we ever run in to performance problems due to this i might consider storing a randomly generated
ETag alongside each document that needs caching. Chanches are this will get revisited as soon as
we have more data in our systems and we run into performance issues.
write test for etag headers and remove debug comments
Merge branch 'feature/add-etag-headers' into develop
fix issue with uncommited mongo config dir

I'm only commenting this since we might add some resources to this bundle at a later stage.
remove unneeded $results var and whitespace in tests
refactor for consistent use of use vs. fully qualified namespacing
refactor long method
more code style consistency fixes and marking up of LegacyValidator issue
php-cs fix
Merge branch 'develop' into feature/generator-bundle
partial (and ugly) implementation of writing controller and services.xml