Core: error handling while plugin start (#693).

When an error occurs very early in the plugin's starting phase (e.g. while reading the plugin.properties file) that error **is** logged and the plugin is **not** retried to start endlessly.

See #693.
Core fix: all errors are logged into file (#694).

If file logging is activated **all** errors are logged into file.
In particular those that occurr while a) bundle start/stop, b) service arrival/removal.

See #694.
Core API change: access static resources (#692).

BREAKING CHANGE

The Core's `Plugin` interface has changed.

1 renamed Method:
{{{
getResourceAsStream() -> getStaticResource()
}}}
The method's semantics has also changed in 2 aspects:
    - when no such resource was found an exception is thrown (instead of returning null). This makes errors more obviuos, in particular when streaming a resource to the client. A bad resource name is reported through an exception instead of letting the browser fail silently.
    - the thrown exception is a runtime exception (instead of an IOException), so you're not strictly required to catch it.

1 new Method:
{{{
boolean hasStaticResource(String name)
}}}
Use this to check if the plugin provides a static resource with the given name. If this method returns true you can be sure that `getStaticResource()` will not throw an exception.

In preparation of "Plugin framework: easify access to plugin's own resources".

See #692.
Core: easify static resource access (#692).

`PluginActivator` has a new method:
{{{
InputStream getStaticResource(String name)
}}}
Use this to access a static resource of your plugin.
The argument is the resource name: a "/"-separated path name, relative to the plugin bundle's root directory. It may or may not begin with "/" (it makes no difference).

So, you don't need to call `dms.getPlugin(yourPluginUri)` anymore.
And you don't need to catch any exception.

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