NEST 0.90

This PR introduces some pretty big breaking changes as its a pretty much rewritten `IElasticClient`

## Precursor

NEST dates back to 2010 some of the choices that have been made have since proven not to scale in terms of maintainability. 

* Way too many convenience overloads, meant that there we around 20+ different Index related methods. The original thinking behind this was that each call would have an *Async and *Raw and RawAsync variant. But with `IElasticClient` being quite bulky a lot of calls were simply missing the async and raw variants. 
* Descriptors vs methods with arguments. Not all the calls exposed descriptors and so were limited in what they could describe. This meant that adding unmapped body/request parameters was exercise in juggling overloads without introducing breaking changes.

Starting with NEST 0.11.7.0 a completely generated `IRawElasticClient` was introduced. This meant that `IElasticClient` was no longer tasked with exposing raw calls. 

# A new IElasticClient

This PR has a completely rewritten IElasticClient, dispatching into the IRawElasticClient. Prior to this release both `IRawElasticClient` and `IRawElasticClient` did their own url building and both called the connection directly. Since the url building in `IRawElasticClient` is generated from the official spec it makes a lot of sense to rely on that. This means that the god class `PathResolver` tasked with translating descriptors to paths is no more. 

This PR takes it one step further though and even generates the dispatching that takes a descriptor and calls the right overload of `IRawElasticClient`
see: https://github.com/Mpdreamz/NEST/blob/api-changes/src/Nest/RawDispatch.generated.cs

This means that `IElasticClient` is not tasked with writing tedious/error prone if statements to choose the correct `IRawElasticClient` overload and in most cases only consists of a single line.

compare the old:
https://github.com/Mpdreamz/NEST/blob/master/src/Nest/ElasticClient-ClearCache.cs

vs the new:
https://github.com/Mpdreamz/NEST/blob/api-changes/src/Nest/ElasticClient-ClearCache.cs

This leans heavily on the fact that descriptor classes are tasked with describing the path, querystring, and body of a request. 

The querystring portion of the descriptors is generated as can be seen here:
https://github.com/Mpdreamz/NEST/blob/api-changes/src/Nest/DSL/_Descriptors.generated.cs

(In fact strongly typed representations of the querystrings are also generated here)
https://github.com/Mpdreamz/NEST/blob/api-changes/src/Nest/QueryStringParameters/QueryStringParameters.Generated.cs

The descriptors inherit from base path descriptors using the "curiously recurring template' pattern (0)
https://github.com/Mpdreamz/NEST/tree/api-changes/src/Nest/DSL/Paths

What this means is that descriptors are now really in the forefront and are themselves completely responsible for describing a call. 

Every call on `IElasticClient` is defined using these descriptors:
https://github.com/Mpdreamz/NEST/blob/api-changes/src/Nest/IElasticClient.cs

There's not a problem more lambda's wont solve :)

Convenience methods do exists for common access patterns becuase i.e:

      client.Get<Document>(g=>g.Id(id));

gets annoying rather fast. The extension methods in:
https://github.com/Mpdreamz/NEST/tree/api-changes/src/Nest/ConvenienceExtensions re-introduces some of the convenience methods so that you can still write:

     client.Get<Document>(id);

### Async variants for ALL the calls. 

all the calls now have Async variants, this is no longer a burden to add due to too many overloads.

### Property names and paths are now also strongly typed internally

Propery paths (i.e `myobject.innerobject.field`) and names (the `field` part in the last example) in NEST can be expressed as string or Expression however Expressions were always immediately translated to a string. NEST 0.90 simply stores them in a type `PropertyPath` and `PropertyName` and only when translated when the time comes they are needed. This meant that the class used to do the translation of this paths is not instantiated in gazillion places. In fact everything is now moved in to the `ElasticInferrer` class. This is always available on both the typed and raw client under `.Infer` which can be used to get typenames/indexnames/properypaths. 

# Breaking changes!!

NEST 0.90 is a major release. The 0.90 version is used not to cause confusion with the pending Elasticsearch 1.0 release.

## IElasticClient contract

Many calls will no longer have the same syntax I created an evil test that showcases the usages of the new calls and to what elasticsearch call they translate to here:

https://github.com/Mpdreamz/NEST/blob/api-changes/src/Nest.Tests.Unit/BigBadUrlUnitTests.cs#L41

If something that used to be easy is now very hard or tedious to do please let me know as it might be a good candidate to introduce a convenience extension method for.

## GetFull()/MultiGetFull() are gone

`Get()` in nest was mapped to getting the document directly so GetFull was introduced to get the full response of the GET call of a document. This has been part of nest since 2010 before elasticsearch introduced the `_source` endpoint.

Similarly `MultiGet()` returned `IEnumerable<T>` and `MultiGetFull()` the full `_mget` response. 

`Get()` now returns the response and `Source()` will return the document directly. This is more inline with the elasticsearch's terminology but something that will introduce a lot of breaking changes in applications using NEST. `MultiGet()` now returns the `_mget` response. 
`SourceMany()` and `GetMany()` convenience methods exists to get the `Hit<T>` or `T`'s given an `IEnumerable` of ids quickly though.

## DefaultIndex part of the connectionsettings constructor. 

Also a painful breaking change. A default index has to be provided to `ConnectionSettings` but is not part of its constructor which caused confusion to people new to NEST. 

## Pluralizing of typenames by default is gone

This has been a personal preference of mine that I've been forcing unto everyone using NEST. This meant that if you index an object of type `Person` with id 1 the url for this document would live under `/defaultindex/people/1`. Again super confusing to people new to NEST. If you rely on this behaviour you can call `.PluralizeTypeNames()` on `IConnectionSettings`.




0 - http://stackoverflow.com/questions/16442596/extension-methods-and-type-inference