MODE-2301 Added support for indexes to be updated synchronously or asynchronously

Prior to this commit, all updates to the indexes in the 4.0 codebase were asynchronous. That means that
the Session.save() method added the ChangeSet describing the session's changes onto the event bus and
then returned. All index updates were done in separate listener threads on the event bus, so it's entirely
possible (and perhaps likely) that any updates to the indexes happen after the client's call to Session.save()
returned. The net effect is that the client might make changes and immediately issue a query that would not
find the recently-saved changes. Additionally, there was no way for the client to know when the indexes would
be updated.

With this commit, it is possible to define whether each index is updated synchronously before the
the Session.save() returns, or asynchronously so that index updates are made in a separate thread.
This commit changes the default behavior of the index updates to be *synchronous*.

In a cluster, any changes made on one process are sent via the change bus to the other processes,
and the indexes in those other processes are always updated asynchronously. In other words, if an
index provider keeps copies of the indexes on every process, then only the local indexes are updated
synchronously before save returns -- and that Session.save() does not wait until the indexes in the other
processes are updated.

In order to properly implement this, a small change was made to the ChangeBus to expand the semantic concept
of an "in-thread" listener. Prior to this, "in-thread" meant that the listener only received locally-originating
change sets. Now, it's still possible to do this (and the journal uses this older behavior), but it's also
possible to register a listener such that locally-originating change sets are handled in-thread while remotely
originating change sets are handled asynchronously.