FEATURE: Allow to expose non persisted objects as relation

Allow to expose ValueObjects with new introduced ExposedValueObjectInterface as relations.
Before it was not possible to expose non entities as relations.

Consider request uri when caching endpoint discovery

In some environments there are internal requests between servers and
external requests from browser to server. Those might have different
URIs, e.g. when external requests are passed through a proxy server
but internal are not.

This change adds the web request URI (schema + port + host + path)
to the cache identifier when caching endpoint discovery results.

Resource informatin now uses TypeMap to resolve resource types

Previously the GenericResourceInformation deferred subpackage and type
name from model class names.

The ExposableTypeMap class already holds a mapping form PHP class names
to json api types. Those types come partially from an algorithm similar
to the one used in the Generic Resource Information. On top of that,
there's a YAML configuration here as well as others such as PHP
annotations provided by this package.

The GenericResourceInformation now just fetches the already known type
strings from the ExposableTypeMap object.

BUGFIX: Respect default sorting of repositories when creating Selectable

7.1.8

Merge pull request #29 from netlogix/bugfix/defaultordering-of-reposi…

BUGFIX: Use "@flow\CompileStatic" to collect known types

Flow's ReflectionService should not be used while Flow is running
in Production context. Exposed types and properties / methods are
now collected during compile time. This way we don't have to
rely on the ReflectionService after the classes were compiled

BUGFIX: Use lowercase key in ExposableTypeMap::getClassNameForProperty()

Merge pull request #27 from netlogix/bugfix/lowercase-type-map

BUGFIX: Use lowercase key in ExposableTypeMap::registerKnownPropertyT…

Add default value for Filter in request arguments

The previous implementation just assumed argument values to be present and created an adjusted argument definition. The actual solution was to not only recreate the arguments definition object but to add the default value to the request arguments data storage as well.

Assume default filter if no filter arguments are present ...

... instead of omitting the filter object completely.

Filters are not always meant to limit results more the more arguments they get.
Sometimes a filters default setting is more restrictive than when arguments are provided.

Example:

• Collection of products
• Default filter skips those out of stock
• Additional filter argument to include out of stock products in result

This is only possible if the filter object is always created.

Getter methods changed type detection from other properties

Every getter method annotated with "ExposeProperty" changed the detected type value of the last actual property of a certain class. This could have several effects, like switching a certain type from attribute to relationship or vice versa, or using the wrong class type when searching for a Sorting or Filter class.

Relations were always treated as collections

The previous version assumed all relations were relations.

This didn't fail tests because every collection mechanisms (pagination, filtering, sorting) only get applied when respective GET Arguments are provided, and they usually aren't on for non-collections.

The last commit of 7.1.1 (always result count) however tried to count() not only collections but non-collections as well.