Discovered while working on SERVER-25001.

Even when a command fails or results in a no-op, if that failure was due to the state of the data files at that moment, and the command came with a w:majority write concern, we need to wait for the most recent optime to become committed, so that the data that caused the command to error will be visible on a subsequent majority read. We already do this properly when a command returns a failure by returning false, but if the command throws an exception we don't. This can lead to subtle problems with the maintenance of the config server optime, as well as leading to confusing behavior for users using readConcern:majority reads