Core API: remove Directives parameter, pt1 (#697).

BREAKING CHANGE

The `Directives` parameter is about being completely removed from the Core API.

Already removed from deletion-related Core Service calls and corresponding event listeners.

There is a new static method to get the `Directives` object for the current request (however most plugins will not need it):
{{{
Directives.get()
}}}

Internally the Core maintains the Directives object in a thread-local variable, and removes it once a Jersey request is processed.

See #697.
Core API: remove Directives parameter, pt2 (#697).

The `Directives` parameter is removed from create- and update-related Core Service calls and corresponding event listeners.

Removing the `Directives` parameter from the Core API is now complete.

See #697.
Merge branch 'no-directives'
Core: create transactions by annotation (#698).

A plugin developer can create a transaction just by annotating a resource method. (A resource method is one with a method designator like @GET.) The DM Core takes provisions to "wrap" such an annotated method within a transaction automatically.

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

    @Transactional
    public void aResourceMethod() {
        ...
    }
}}}

See #698.
Adapt to Core change (@Transactional) (#698).

The DM distro plugins make use of the new `@Transactional` annotation.

PLUGIN DEVELOPMENT NOTES

Keep in mind that the Core Service methods (called via the `dms` object) do not create a transaction on its own anymore (but the corresponding resource methods of the Webservice plugin do). So, when your plugin encounters a `NotInTransactionException` exception just annotate your originally calling resource method with `@Transactional`. (A resource method is one with a method designator like @GET.)

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

@Transactional
public void aResourceMethod() {
    ...
}
}}}

Note that the majority of your plugin methods are triggered originally by an HTTP request (directly or indirectly), that is a resource method. Annotating that resource method is sufficient. (In fact `@Transactional` annotations on non-resource methods are ignored.) Most plugins are not required to create a transaction imperatively anymore.

However, there are cases when your plugin methods are *not* triggered by a HTTP request. These cases include
    - the `allPluginsActive()` event handler
    - tests
    - DM service calls from non-DM OSGi bundles

In these cases you're required to create the transaction imperatively, just as you did before:
{{{
    import de.deepamehta.core.storage.spi.DeepaMehtaTransaction;

    public void aMethod() {
        DeepaMehtaTransaction tx = dms.beginTx();
        try {
            ...
            tx.success();
        } catch (Exception e) {
            logger.warning("ROLLBACK!");
            throw new RuntimeException("Something failed", e);
        } finally {
            tx.finish();
        }
    }
}}}

Note: calling a `@Transactional` annotated resource method from another `@Transactional` annotated resource method is OK. No nested transaction will be created. (Nested transactions are not problematic anyway.) Keep in mind a transaction is only created for the resource method the original HTTP request is mapped to. So, typically there is a 1:1 relationship between transaction and HTTP request.

See #698.
Core: fix cookie access (#696).

When `Cookies.get()` is called outside a request scope no exception is thrown. Instead an empty `Cookies` object is returned.

See #696.
Merge branch 'transactional-at'
Merge branch 'master' into workspace-acl