Remove ClientState parameter from Core API (#696).

BREAKING CHANGES

The `clientState` parameter is completely removed from all APIs.
So, just drop it from all your method calls.

If your plugin needs access to the cookies inject `HttpHeaders` and construct a `Cookies` object on it.
`Cookies` is a new class which is call compatible to the former `ClientState` (which is dropped).

Example:
{{{
import de.deepamehta.core.service.Cookies;

import javax.ws.rs.Path;
import javax.ws.rs.core.Context;
import javax.ws.rs.core.HttpHeaders;

@Path("...")
public class YourPlugin ... {

    @Context
    private HttpHeaders httpHeaders;

    void someMethod() {
        Cookies cookies = new Cookies(httpHeaders);
        ...
    }
}
}}}

Note: injecting the HTTP headers only works in a root resource class, that is a class which has a `@Path` annotation.

IMPORTANT: the DM standard distro is not yet working, in particular the Workspaces plugin. This is because we can't cheat anymore by passing `null` as `clientState`. The Workspace plugin did this to avoid the vicious circle that occurs when an workspace assigment (an `Aggregation`) gets itself an workspace assignment, which gets itself ...

To solve this situation we aim to solve #341 ("Association Definitions with custom Association Types") first. We will introduce a dedicated association type `Workspace Assignment` then. This allows the Workspace plugin to skip workspace assignment in case a `Workspace Assignment` association is detected. A generic `Aggregation` in contrast can not be distinguished ... ooh, hey, let's wait a minute ... while I'm writing this the solution becomes evident: of course an Aggregation can be recognized as a workspace assignment: by checking the involved players! OK, lets go this way. Lets wait #341 a little.

See #696.
Adapt plugins to Core changes (#696).

Remove ClientState parameter from all methods.

See #696.
Remove ClientState: fix Workspaces plugin (#696).

Remove vicious circle that would occur when assigning a workspace to an workspace assignment (association of type Aggregation).

See #696.
Core: fix plugin start error handling (#693).

Errors like `NoClassDefFoundError` are not thrown through the OSGi container.
The phenomenon of "swallowed" exceptions and endlessly retried plugin starts is eliminated once and for all!!

Close #693.
Merge branch 'no-clientstate'
Core API: easify cookie access (#696).

BREAKING CHANGE

If your plugin needs access to the current request's cookies just call `Cookies.get()`.
This works in any class.
Internally the Core stores the current request (and thus the cookies) in a thread-local variable.

Example:
{{{
import de.deepamehta.core.service.Cookies;

public class YourPlugin ... {

    void someMethod() {
        Cookies cookies = Cookies.get();
        ...
    }
}
}}}

This is much more easy than the recently introduced approach (which worked in root resource classes only):

{{{
import de.deepamehta.core.service.Cookies;

import javax.ws.rs.Path;
import javax.ws.rs.core.Context;
import javax.ws.rs.core.HttpHeaders;

@Path("...")
public class YourPlugin ... {

    @Context
    private HttpHeaders httpHeaders;

    void someMethod() {
        Cookies cookies = new Cookies(httpHeaders);
        ...
    }
}
}}}

See #696.
Adapt plugins to Core change (cookies) (#696).

Easify cookie access.

See #696.
More telling log in case of updated plugin (#693).

When an error occurs while event handling, in particular an error caused by an outdated plugin (not yet adapted to Core API changes) like `NoSuchMethodError` or `AbstractMethodError` the log is more informative in that case.

Close #693.
Merge branch 'master' into workspace-acl