Initial Newtonsoft datum serializer

Initial implementation of Newtonsoft's datum serializer for RethinkDB.

In reference to #149.

Core Changes
-----

Two file changes to the core **rethinkdb-net** core were made since I couldn't find any other way to "hook" the Newtonsoft serializer. I think this is related to #150. You'll see these changes in the following:

> DefaultConnectionFactory.cs<br>ConfigurationAssembler.cs

I tried to set my serializer just soon after the connection was built, but I ran into an issue that the `DatumConverterFactory` on the connection could not be set due it being wrapped. So, please feel free to revert this change and make it more appropriate for #150.

Newtonsoft Datum Serializer
-----

Generally speaking, the Newtonsoft Datum serializer uses **rethinkdb-net**'s native datum converters for primitive types, nullables, and DateTimes. There was no sense in reinventing the wheel here.

Conceptually, Newtonsoft as uses a `Reader` and `Writer` to write formats.

The core of the serializer is `DatumReader` and `DatumWriter` that read and write datums, respectively.

`DatumWriter`
-----

There is nothing too exciting with the `DatumWriter`, it was the first, and easiest to write. Basically, it uses a stack to keep track of the write signals we get from Newtonsoft. Ultimately, when everything is done writing, you can retrieve the root datum by calling `GetRootDatum()` as done by `DatumConvert.SerializeObject()`.

The following `DatumWriter.WriteValue(TimeSpan)` overloads are ***intentionally*** left not implemented:
```cs
        public override void WriteValue( TimeSpan value )
        {
            throw new JsonException( "TimeSpans can only be converted by including the DatumTimeSpanConverter in JsonSeralizerSettings. See source comment for: DatumTimeSpanConverter." );
        }

        public override void WriteValue( TimeSpan? value )
        {
            throw new JsonException( "TimeSpans can only be converted by including the DatumTimeSpanConverter in JsonSeralizerSettings. See source comment for: DatumTimeSpanConverter." );

        }
```

The reason for this is because we are doing custom serialization for `TimeSpan` using float seconds.

`TimeSpan` serialization is handled by a special `TimeSpanConverter` that must be added to the serializer's `JsonSerializerSettings`.

```cs
 new JsonSerializerSettings
                {
                    Converters =
                        {
                            new TimeSpanConverter()
                        },
                    ContractResolver = new CamelCasePropertyNamesContractResolver()
                };
```

See `NewtonsoftDatumConverterFactory` for how this is done. You'll notice the default `JsonSerializerSettings` is using `CamelCasePropertyNamesContractResolver`, this is so all properties get serialized with camel case property names.

`DatumReader`
-----

The reader is somewhat more complicated. Took me a few times to get right. 

The meat of the `DatumReader` is the `Read()` which calls `ReadInternal()` which stages / syncs, the internal `JsonReader` state machine.

Given a `CurrentState`:

* You must `SetToken()` appropriately and `return true` if there is more to deserialize.
* Or, you must `return false` to signal the end of deserialization.

Sometimes this simple state checking can get short-circuited when Newtonsoft knows more about the "type" it's reading. Newtonsoft can call `ReadAsDateTime()` in the middle of reading which kinda throw things off when you're expecting a `Read()`. This is why the `ReadInternal` has a signature `ReadInternal(ReadAs? readAs = null)`. If `ReadAs` is set, it's an indication that Newtonsoft is telling us to do a more "forceful" read of the underlying data. `ReadAs` is eventually carried to `ReadAsSpecialType` where special case datums are converted (for example `DateTime` `$reql_type$`).

More about `TimeSpanConverter`
----

Don't attempt to squeeze the `TimeSpan` conversion code into the `DatumReader` because it won't work. There's not enough type information at **read time** to differentiate what is **currently** being deserialized: a `TimeSpan` or a `decimal`.

This is why it's **essential** for the `TimeSpan` conversion code to exist as a `TimeSpanConverter`. Otherwise, dangerous dragons will be met.


Keep `DefaultSeralizerSettings` public
----

One last note, it's really important keep the `DefaultSeralizerSettings` for the serializer **public** so that it can be modified by the user. It's important because this is how the behavior of the Newtonsoft serializer can be modified. For example, the user might want to add an additional converter like `StringEnumConverter` which converts `enum`s to their string representation instead of their underlying type values.


Other
-----

* **FluentAssertions** is referenced and added to **rethinkdb-net-newtonsoft-test** project to help with datum object graph comparisons. You'll see quite a few `ShouldBeEquivalentTo()` datum comparisons which itterate over the datum object graph that checks for datum equality between what is expected and what the Newtonsoft serializer does. Couldn't help it, it comes in really helpful. See http://fluentassertions.codeplex.com/documentation.


Thanks,
Brian Chavez