Rationalize handling of server default vs. not-provided read concern, write concern

A read concern of nil can mean different things, depending on the context.

If a client/db/collection's readConcern property is nil, that means it does not have a read concern set on it / it is using the server default read concern.

However, imagine a user does the following:

let client = try MongoClient(options: ClientOptions(readConcern: ReadConcern(.local)))

let db = client.db("foo", options: DatabaseOptions(readConcern: nil))

In this case, you might imagine that the nil read concern provided for the DB would override the local read concern that the db will by default inherit from the client.

However, that is not the case. Doing DatabaseOptions(readConcern: nil) is equivalent to doing DatabaseOptions(). So the db will end up with the local read concern inherited from the client.

One proposed solution is to implement an enum that is like an optional but has three states: some, none, and default.

Alternatively we stop using nil to mean default/unset read concern, and just use an empty read concern ReadConcern().

All this applies to WriteConcern as well.