Enhanced Support for browser Actor proxies

[dpp]

Added support to serverActorForClient to register for life cycle events as well as filtering the data before
it's sent to the client.

Opened and documented serverActorForClient so folks can add custom CometActors that
are programmatically generated rather than named.

[Shadowfiend]

This is like way late for me to be asking this, @dpp, but what was the reasoning behind exposing this instead of just using S.findOrCreateComet[T], which also handles ensuring that names are unique in the session? Wanted to drop a note about it in the release notes.

[dpp]

I needed a place to dynamically create CometActors rather than refer to a CometActor that had been compiled with the project. Now how can one dynamically subclass a JVM class without compiling it with the project? Yep... it was some of the Scala/Clojure/Lift/Reagent inter-op stuff I've been doing.

But more broadly, I realized that there might be times even in pure Scala-land that one might want to do a:

new CometActor { ..... }

Rather than creating a separate CometActor subclass in a file with a name.

[Shadowfiend]

Aha! So the key here is the access to newCometFn that can produce an arbitrary T <: LiftCometActor, right? Can you drop a sample use here so I can use it in docs/release notes, by any chance? If not I'll just do some digging around myself :)

[dpp]

Okay... here's an example https://github.com/dpp/devoxx_pl_2015_scala_clojure/blob/alt_comet/src/main/scala/sb/snippet/Actorize.scala#L29

I wound up extending serverActorForClient to include the lifecycle call-backs... but I liked the idea of being able to create an arbitrary CometActor class and maybe close over local scope rather than do the wonky "send a message and put the variables from the message in vars" paradigm. So I left buildAndStoreComet public.