Callback exceptions in execute block no longer suppressed

I came across a recent inconsistency dealing with Callbacks.  Essentially, running

```
Callback.success("foo").execute{_ => throw new Exception("failed")}
```
would throw the exception, but 
```
Callback.success("foo").flatMap(_.toUpperCase}.execute{_ => throw new Exception("failed")}
```
would not.  This ended up being because in one place in `flatMap`, we're mapping on a `Try` but never doing anything if the `Try` is a `Failure`.  

This is kind of a weird situation because in most cases doing something like:
```
try {
  Callback.success("foo").flatMap(_.toUpperCase}.execute{_ => throw new Exception("failed")}
} catch {
  //...
}
```
will *not* work, because often the contents of `execute` are not actually executed in this block (such as when sending a request to a client).  So we have two options here.  Always suppress thrown exceptions in the execute block, or always throw them.  As of now I've decided to go with the latter, as it's probably better to be noisy and crash things than silently fail.  

This means it is now the responsibility of any code that builds and executes Callbacks to be aware of the possibility of a `CallbackExecutionException` being thrown.  However in most cases this is generally not a big deal.  This _only_ affects the final block of code passed in the call to `execute`, and so far in Colossus users never call `execute` themselves; it's done by the service layer.  Also right now nowhere in Colossus do users actually create Callbacks, they only get them when calling `send` on a service client.
yes, but it's a little tricky because we don't want to completely make the method unavailable, since for more custom use cases (not in services) you'll definitely need to call it yourself.

I've been thinking about doing possibly a couple traits, one used only by service clients that doesn't have the execute method, and another more general version that does have execute available.  Needs some more thought because on the other hand I don't want to start making a ton of traits that makes things more confusing.