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.
This comment caught my eye.  Is there anyway to prevent client code from having access to that execute method?  Via Traiting, subclassing, etc?  I know we cannot totally stop it, but maybe masking it might be a good enough preventative measure?