Let the ActorSystem find its configuration outside of the bundle, in the OSGi etc directory, following this order:
    etc/bundle-BUNDLE_SYMBOLIC_NAME.conf
    etc/bundle-BUNDLE_ID.conf
    etc/akka.conf
    akka-actor classpath config (using the original  OsgiActorSystemFactory.actorSystemConfig method.)

Configurations fallback from the most to the less specific one.

For the moment, as I haven't found test on ActorSystem Configuration in OSGi, I did not add test for this feature.
    	modified:   akka-osgi/src/main/scala/akka/osgi/OsgiActorSystemFactory.scala
Concerning akka in osgi:
ActorRefProvider contains in akka-cluster or akka-remote bundle are not found by the akka-actor bundle, thus exposing those if required
half-done PoC of typed channels
add selfChannel and createChildren
clean it up a little

- remove Parent trait and use ChannelList to describe the parent
- remove ugly hack and switch to erasure-based dispatch to the channels
- add parentChannel
- make ChannelRef a value class
replace Channel[] trait with simple Tuple2 for nicer syntax
 patriknw comments commited

        * .conf, .properties, .json configuration files
        * string interpolation
        * take place of the legacy actorSystemConfig
change Recv[] from partial to total function

- also change :=: to :+: for faster typing pleasure on US keyboards
add tests for parentChannel
add ChannelRef.narrow[]
add narrowing from ActorRef to ChannelRef
rkuhn comments applied: no more extension
add polymorphic channels

- channel[T <: ChannelList] takes a WrappedMessage[T] => Unit function
  because there cannot be a typed sender reference (which type would it
  have?)
- ChannelRef[T] allows forwarding of WrappedMessage[T] (and nothing
  else; keeping the sender is essential)
- move ActorRef.narrow implicit into the package object
- do not accept top-level Channels which send to their parent
add typed ask support
add check for same-erasure channels
add check that all channels were declared
add verification of ping-pong chains

- basic principle is that if we get a reply of type T1 and our channels
  allow us to reply to such a message with type T2, then the target
  needs to support that as well, and so on.
- due to this, forwarding will have to be restricted; but it might well
  be that forwarding will not be completely safe in any case
Publish clean state when joining (PublishStart), see #2871

* The failure in JoinTwoClustersSpec was due to missing publishing
  of cluster events when clearing current state when joining
* This fix is in the right direction, but joining clusters like this
  will need some design thought, creating ticket 2873 for that
 #2879 - updating copyright info
Adjust protocol pattern in LogRoleReplace for new remoting