Spike/dispose

[Mpdreamz]

This PR add IDisposable to some of our moving parts that (may) need it.

Historically we did not do this because this parts are expected to live for the duration of your application but it does not hurt to be explicit.

SniffingConnectionPools holds a ref to ReaderWriterLock which needs to dispose some events.
Transport held a SemaphoreSlim which really holds a system handle.

The ownership of the semaphore (used for sniffing on startup) moves to ConnectionSettings with this PR because new ElasticClient() implicitly creates a new Transport() each time, eventhough the IConnectionPool interface is already resilient to this it means we create more Semaphores then strictly needed if folks are new'ing clients all the time.

Therefore this PR also introduces some documentation on the recommended life times of our objects.

See this test for more info

The interfaces implement IDisposable for it's Level1 disposables using the pattern as outlined by Stephen Cleary:

http://www.codeproject.com/Articles/29534/IDisposable-What-Your-Mother-Never-Told-You-About

No object disposed exceptions are thrown as the previous article explains:

Instead of checking for the disposed state and throwing an exception, I recommend supporting "undefined behaviour". Accessing a disposed object is the modern equivalent of accessing deallocated memory.

To help prevent getting into this state all the Dispose() methods are explicitly implemented.

More rants against the classical dispose pattern: http://blogs.msmvps.com/peterritchie/2013/01/20/the-dispose-pattern-as-an-anti-pattern/

[garymcleanhall]

Sweet, glad this is being sorted. Thanks!

[gmarz]

Left one minor nitpick comment, but otherwise this looks good. Really like the documentation tests. 👍

[Mpdreamz]

Good catch @gmarz updated 👍