Proof-of-concept refactor for sending packets

I decided to break this change up into more digestible pieces, but the general idea here is to make greater use of queues to further decouple core Lantern classes. The key conceptual change is illustrated in the following:

```java
-    @Override
+    @Subscribe
      public void sendPacket(final Packet packet) {
```

The @Override is only relevant in that removing it means we're removing that method from the implemented interface. Since classes only know about that method via the interface, this effectively means that we're saying that method should now never be called. 

It will now only be called if another class creates a Packet "event" via something like the following:

```java
Events.asyncEventBus().post(packet);
```

This is handy because any class that wants to send an XMPP message can now be fully decoupled from the actual class that sends the message (DefaultXmppHandler). This is very similar to actors in Akka, which is really borrowed from Erlang (although without the same degree of fault tolerance), and it makes concurrency easier because all of this stuff can be happening on whatever thread you feel like without thinking about it (as long as the data in the queues is immutable). We're basically using the Guava events library as a poor man's Akka, but Guava events are pretty handy in this regard because they're super easy to use and less disruptive to the code (plus Akka is friggin' huge!).

The only downsides I think are potential performance implications and lack of compile time checking (you're effectively calling a method on another actor without making sure of that at compile time).

Anyway, we could take this much further to fully decouple most modules in Lantern and to have them simply pass data between them, so the focus becomes that flow of data.