Add aliases support for relationships

[neomerx]

From spec: A server MAY choose to expose a deeply nested relationship such as comments.author as a direct relationship with an alias such as comment-authors. This would allow a client to request /articles/1?include=comment-authors instead of /articles/1?include=comments.author. By abstracting the nested relationship with an alias, the server can still provide full linkage in compound documents without including potentially unwanted intermediate resources.

It used to be excluded by default for nested relationships (and it is implemented in RC3). Now this functionality has to be changed to work with aliases. See related #15

[neomerx]

Currently it is possible to declare such relation (e.g. comment-authors) and return anything including nested relationships with any depth. However if such a relationship is declared in Schema it will be returned to user on every call. So if a developer wants this relation loaded only when requested it should be more than one Schema or one configurable Schema that returns various results for getRelationships. Also it should be considered that allowed field sets should be integrated with this logic as well.
It's all could be done and the key question how do we want it to actually work?

[neomerx]

As declared earlier relationship aliases are naturally supported. If a developer wants this relationships to be loaded conditionally then such support should be added to Schema with sensible defaults. Changes of the default settings are outside of this package scope however possible approaches are described in here. They are

• changes via getConfig() Controller's method
• setting up an encoder with custom schema with setSchema Controller's method