LOGBACK-836: Added security checks to methods controlling the state of the logging system

As described in http://jira.qos.ch/browse/LOGBACK-836 any code can alter the state of the logging system, such as starting/stopping the context, adding/removing appenders, setting logger levels, etc. To restrict the access to those methods while running with standard Java security enabled, checks if the caller domain does have the appropiate permission are necessary. I added some simply `checkPermission()` calls prior to the execution of those methods. There should be no performance penalty if security is disabled, because `checkPermission()` does nothing if no _SecurityManager_ is set.

The following control methods are being protected:
* LoggerContext
 * `addListener`
 * `addTurboFilter`
 * `getExecutorService`
 * `getFrameworkPackages`
 * `getStatusManager`
 * `getTurboFilterList` (because it is mutable)
 * `putObject`
 * `putProperty`
 * `removeListener`
 * `reset`
 * `resetTurboFilterList`
 * `setMaxCallerDataDepth`
 * `setName`
 * `setPackagingDataEnabled`
 * `setStatusManager`
 * `start`
 * `stop`
* Logger
 * `addAppender`
 * `detachAndStopAllAppenders`
 * `detachAppender`
 * `getAppender`
 * `iteratorForAppenders`
 * `setAdditive`
 * `setLevel`

Some notes on the patch provided by this pull request:

1. I tried to to follow the present code style. The methods in some classes are not sorted alphabetically, so I added the overridden methods at conventient locations.
1. The `checkPermission()` method is a package-private static method of the _LoggerContext_ class and is reused be the _Logger_ class. I did this to avoid creating a new utility class (e.g. _SecurityUtil_).
1. I reused _java.util.logging.LoggingPermission_ as the permission to be checked. The reuse of this JUL class dramatically simplifies the deployment in an OSGi environment as no extension to the system bundle is necessary.
1. As the checks are simple I did not create unit tests.