Core API wording: rename CompValue pt.1 (#702).

BREAKING CHANGES

Classes/Interfaces:
{{{
CompositeValue -> ChildTopics
    getCompositeValue() -> getChildTopics()
CompositeValueModel -> ChildTopicsModel
    getCompositeValueModel() -> getChildTopicsModel()
}}}

DeepaMehtaObject:
{{{
getCompositeValue() -> getChildTopics()
setCompositeValue() -> setChildTopics()
}}}

DeepaMehtaObjectModel:
{{{
getCompositeValueModel() -> getChildTopicsModel()
setCompositeValue() -> setChildTopicsModel()
}}}

See #702.
Core API wording: rename CompValue pt.2 (#702).

BREAKING CHANGE

The topic/association's JSON property `composite` is renamed to `childs`.
{{{
{
    "id": ..,
    "uri": ..,
    "type_uri": ..,
    "value": ..,
    "childs": ..    ### was "composite"
}
}}}

Plugin developers are supposed to carefully update the JSON migrations and client-side code.

See #702.
Core API wording: rename CompValue pt.3 (#702).

BREAKING CHANGE

REST APIs: the `fetch_composite` query parameter is renamed to `include_childs`.

Example:
{{{
GET /core/topic/1234?include_childs=true    ### "include_childs" was "fetch_composite"
}}}

Plugin developers are supposed to carefully update client-side code.

NOTE: the former `fetch_relating_composite` query parameter to include the (relating) association's child topics in the response is not supported at the moment. Do we actually need it in the REST APIs? If so, it should be renamed to `include_assoc_childs` and be implemented in the Core's `JerseyResponseFilter` (analogous to `include_childs`).

See #702.
Core API wording: rename CompValue pt.4 (#702).

Just rename variables and adapt comments.

See #702.
Merge branch 'compvalue-wording'
Parent POM: restore version 5.

When updating to OSGi 5 and Jetty 8 (commit 82d04a36) we accidentally changed the Parent POM without bumping its version number (from 5 to 6). This prohibits the external DM 4.3 compatible plugins from being build.
Revert "Parent POM: restore version 5."

This reverts commit 4c200f5d454bc92672fc1c18afa735557478ea73.
Parent POM: bump version number to 6.

The DM 4.4 standard modules depend on parent POM version 6 due to updated OSGi 5 and Jetty 8 dependencies, besides other (see commit 82d04a36).
HTTPS configuration for Pax Web (#448).

New config properties in global POM:

    `org.osgi.service.http.port.secure` -- The HTTPS port. Default is 8443.

    `org.osgi.service.http.secure.enabled` -- To enable HTTPS set this to `true`. Default is false.

    `org.ops4j.pax.web.ssl.keystore -- The path to the .keystore file.

    `org.ops4j.pax.web.ssl.password` -- The **Key Password** (as entered in the `keytool`).

    `org.ops4j.pax.web.ssl.keypassword` -- The **Keystore Password** (as entered in the `keytool`).

Note the confusing wording of the 2 Pax Web password properties.

For `keytool` usage to create a keystore and a key pair and a self-signed certificate see #295.

See #448.
Fix HTTPS default configuration values (#448).

See #448.
Distribution: fix building standard distro (#706).

Building the DM Standard Distro works again (was broken 3 days ago).

The distribution build files and config files are adapted to Pax Web and Felix 4.4

See #706.
Webservice: getRelatedAssociations() (#707).

The `Topic`'s `getRelatedAssociations()` method is RESTful:
{{{
GET /core/topic/{id}/related_assocs
}}}
Result is an array of associations (may be empty).

To filter the result set the usual 4 traversal query parameters can be applied (all optional):
{{{
assoc_type_uri
my_role_type_uri
others_role_type_uri
others_topic_type_uri
}}}

Note: the `include_childs` query parameter is not yet supported.

See #707.
Core: include_childs for association lists (#699).

All REST APIs: the Core's `JerseyResponseFilter` processes the `fetch_composite` query parameter also for Iterable<Association> responses.

In particular this works for the `GET /core/topic/{id}/related_assocs` request (see #672, see #707).

See #699.
Core API: orthogonal traversal methods (#707).

`DeepaMehtaObject` base interface has 2 new methods:
{{{
RelatedAssociation getRelatedAssociation(String assocTypeUri,
                                         String myRoleTypeUri,
                                         String othersRoleTypeUri,
                                         String othersAssocTypeUri)

ResultList<RelatedAssociation> getRelatedAssociations(String assocTypeUri,
                                                      String myRoleTypeUri,
                                                      String othersRoleTypeUri,
                                                      String othersAssocTypeUri)
}}}
Corresponding/similar methods are removed from the `Topic` and `Association` sub interfaces (see BREAKING CHANGES).
This make the tranversal API more orthogonal. In particular the 2nd method can now be called on `Association` objects as well.

`ResultList` has a new method:
{{{
void add(T item)
}}}

BREAKING CHANGES

- `Association`'s `getRelatedAssociation()` method has a 4th parameter: `othersAssocTypeUri` (analog to `Topic`'s `getRelatedAssociation()` method)

- `Topic`'s `getRelatedAssociations()` method returns a `ResultList` instead a `List` (analog to the `getRelatedTopics()` counterpart).

Core Service API:

- `getAssociations(String assocTypeUri)` returns a `ResultList` instead a `List` (analog to the `getTopics()` counterpart).

Core REST API:

- The `GET /core/topic/{id}/related_assocs` request (introduced 5 days ago) returns a `ResultList` instead a `List` (analog to the `/related_topics` counterpart), that is
{{{
{
    "items": [
        ...
    ],
    "total_count": ...
}
}}}
instead the plain array.

See #707.
Webservice: getAssocRelatedAssociations() (#707).

The `Association`'s `getRelatedAssociations()` method is RESTful:
{{{
GET /core/association/{id}/related_assocs
}}}
Result is a 2-property object:
{{{
{
    "items": [      # array of associations (may be empty).
        ...
    ],
    "total_count": ...
}
}}}

To filter the result the usual 4 traversal query parameters can be
applied (all optional):
{{{
assoc_type_uri
my_role_type_uri
others_role_type_uri
others_assoc_type_uri
}}}

The `include_childs` query parameter is supported as well.

The Core's traversal API including its REST API is now fully orthogonal.

See #707.
Webclient: create custom role types (#680).

To create a custom role type use the Create menu's new item "New Role Type".
Enter a human-readable name and an URI.
Every role type needs an URI. A default URI is provided automatically.

Core Service API:

- `createRoleType()` is a new method

Webclient API:

- do_create_role_type() is a new controller method
- create_role_type() is a new storage method

REST Client:

- create_role_type() is a new method

See #680.
Merge branch 'master' into workspace-acl