Subscriber defined threading.

In many event buses, the event poster is responsible for deciding what thread the event will be delivered on. This often leads to confusion and subtle threading bugs. This confusion may be duplicated on every event post.

This patch adds an *optional* `thread` parameter to the Subscribe annotation. This lets the subscriber define what thread it needs to run in. 

```java
@Subscribe(thread=ExecuteOn.BACKGROUND) updateDatabase(UpdateEvent event);

@Subscribe(thread=ExecuteOn.MAIN) updateUi(UpdateEvent event);

@Subscribe(thread=ExecuteOn.ASYNC) updateRemoteServer(UpdateEvent event);
```

```java
void update() {
   bus.post(generateUpdateEvent());
}
```
It is backward compatible with noarg `@Subscribe` annotations. The annotations on the following two method signatures have identical semantics.

```java
@Subscribe updateInAnyThread(UpdateEvent1 event);

@Subscribe(thread=POSTER_DECIDES) updateInAnyThread(UpdateEvent2 event);
```

This is a strawman implementation that defines four possible choices of threading that a subscriber can run on: 

 * `MAIN` - the UI thread, 
 * `BACKGROUND` - a single background thread, 
 * `ASYNC` - a thread from an unbounded thread pool and
 * `POSTER_DECIDES` - the current behavior. This is the default.

For best effect use `ThreadEnforcer.ANY`, so events can be posted from non-ui threads. 

```java
bus = new Bus(ThreadEnforcer.ANY);
```
This should solve previously closed issues #14 and #38 reasonably cleanly.