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());
}
```

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.