Revise Workspaces model and API (#262).

Workspace assignments are facets (as provided by the Facets plugin).
The Workspaces API is reshaped to be more generic. Workspaces can be assigned to associations as well.
There are just 3 methods:
{{{
Topic createWorkspace(String name)

void assignWorkspace(DeepaMehtaObject object, long workspaceId)

Set<RelatedTopic> getAssignedWorkspaces(DeepaMehtaObject object)
}}}

The Workspaces data model has changed:
    - Drop association type "Workspace Context" ("dm4.workspaces.workspace_context")
    - Drop role type "Workspace Topic" ("dm4.workspaces.workspace_topic")
    - Drop role type "Workspace Type" ("dm4.workspaces.workspace_type")

Old:
{{{
                      association type "Workspace Context"
    Workspace <------ ("dm4.workspaces.workspace_context") ------> Topic
        role type "Default"                         role type "Workspace Topic"
        ("dm4.core.default")                        ("dm4.workspaces.workspace_topic")

                      association type "Workspace Context"
    Workspace <------ ("dm4.workspaces.workspace_context") ------> Type
        role type "Default"                         role type "Workspace Type"
        ("dm4.core.default")                        ("dm4.workspaces.workspace_type")
}}}

New:
{{{
                   association type "Aggregation"
    Workspace <------ ("dm4.core.aggregation") ------> DeepaMehtaObject (Topic, Type, ..)
        role type "Part"                                   role type "Whole"
        ("dm4.core.part")                                  ("dm4.core.whole")

}}}

In the new model a workspace assignment is a core aggregation ("Many").
The workspace is a facet ("Part") of the object ("Whole").
There is no distinction between Topic or Type objects.

IMPORTANT: for production installations the admin must provide a
migration to convert the workspace assignments to the new model.
For test installations the DB must be reset.

In preparation for the MEMBER user role of the Access Control plugin.

See ticket 262.
Access Control: assign types to workspace (#262).

The topic types of the DeepaMehta Standard Distribution are assignedd to the default workspace.
The default workspace is now called "DeepaMehta" (formerly "Default").

In preparation for the MEMBER user role of the Access Control plugin.

Fix: searching for a workspace by name finds the workspace (instead of all the topics assigned to it).

Furthermore in Core:
The pseudo-type "Meta Meta Type" ("dm4.core.meta_meta_type") is not introduced to plugins.

See ticket 262.
Merge branch 'accesscontrol' into member-role
Access Control: MEMBER is ACL default role (#262).

A topic can be edited by the members of all workspaces the topic is assigned to.
Topics can be created by the members of all workspaces the respective type is assigned to.

The default user ("admin") is assigned to default workspace ("DeepaMehta").
New users are assigned to the current workspace by default (not yet functional).

Thus, collaboration with equal permissions within workspace borders is the default setup.

ACL model change:
The association type "Membership" (dm4.accesscontrol.membership) is dropped.
Instead the Username topic's regular workspace assignment is interpreted as a membership.

Facets API:
    - hasFacet() is a new method

Workspaces API:
    - isAssignedToWorkspace() is a new method
    - getDefaultWorkspace() is a new method

Workspaces fix:
    - updating workspace assignment works

See ticket 262.
Access Control: fix user account creation (#262).

New users are assigned to the current workspace, and thus get proper permissions.
New user accounts are functional.

IMPORTANT for plugin developers: when calling dms.createTopic() make sure to pass the ClientState.
Otherwise the new topic get no workspace assignment, and thus will not be editable by default.

See ticket 262.
Fix Access Control for default topicmap (#262).

The default topicmap is guaranteed to have a) an workspace assignment, b) an ACL entry, and c) a creator information.

See ticket 262.
Webclient: association associated topics (#306).

When an association is selected the detail panel lists the topics associated with that association.
Clicking a topic reveals it on the canvas.
However, the associating association is not displayed on the canvas.

Webservice API:
    - GET /core/association/{id}/related_topics?... is new request

RESTClient API:
    - dm4c.restc.get_topic_related_topics() replaces get_related_topics()
    - dm4c.restc.get_association_related_topics() is new method

RenderHelper API:
    - dm4c.render.topic_associations() replaces associations()
    - dm4c.render.association_associations() is new method

IMPORTANT: if your plugins make use of the replaced methods they must be adapted.

See ticket 306.
Merge branch "master" into "accesscontrol".

Webclient: association associated topics (#306).
Merge branch 'accesscontrol' into member-role
Setup associations for Access Control (#262).

New associations are assigned to the current workspace, and thus are properly setup for access control.

IMPORTANT for plugin developers: when calling dms.createAssociation() make sure to pass the ClientState.
Otherwise the new association get no workspace assignment, and thus will not be editable by default.

See ticket 262.
Merge "dgf/deepamehta accesscontrol" (#305).

ItemKind is a top-level class and is reused in ResourceInfo.

According to the original pull request 2 changes were made:

1) FileItem is still an inner class of DirectoryListing.
   It is only needed there.

2) ItemKind is serialized via stringify().
   We never want the program logic to rely on the toString() value.
   toString() is exclusively used for user-friendly logging messages.

Thanks, dgf for the patch!

See ticket 305.
Merge branch 'accesscontrol' into member-role
Workspaces: fix exception handling.

This reveals an error dgf has reported:
{{{
ID 35158 refers not to a MehtaNode but to a MehtaEdge
}}}

The error itself is not yet fixed.
Core: fix association update.

This error does not occur anymore:
{{{
ID 35158 refers not to a MehtaNode but to a MehtaEdge
}}}
This was caused by the more strict argument checking as recently introduced in MehtaGraph.

Thanks, dgf for reporting!

New method in DeepaMehtaObject interface:
{{{
Association getAssociation(String assocTypeUri, String myRoleTypeUri, String othersRoleTypeUri, long othersTopicId)
}}}