Use new System.IO.Pipelines API / Project Bedrock

Benefits
--------

* Pooled memory management reducing allocations.
* Instead of current message pump design of pulling/pushing bytes out of a `NetworkStream` and using `CancellationTokenSource`; we can leverage some of the low-level network code that ASP.NET Core is using.
* Should allow us to consolidate/delete a lot of code in `SocketWrapper.cs`.
* Should help us get the best performance out of the driver from the network when implementing #77.

Disadvantages
---------------
* Requires **.NET Core 2.1** (I think)

References
-----------
* ASP.NET Community Standup - May 1, 2018 - SignalR and Project Bedrock with David Fowler
https://www.youtube.com/watch?v=ySmUI8O1Rog

* Microsoft Build 2018: 1:15 PM | Meet the new stack for real-time web communication: ASP.NET Core SignalR
https://www.youtube.com/watch?v=u0_vkWYYXRc
https://channel9.msdn.com/Events/Build/2018/BRK2147

* Links:
https://blogs.msdn.microsoft.com/dotnet/2018/04/18/performance-improvements-in-net-core-2-1/
https://blog.marcgravell.com/2018/07/pipe-dreams-part-3.html

* Related #77

Start by reviewing SocketWrapper.cs and the current message-pump design, then read the related #77 issue and the referenced ASP.NET Core and System.IO.Pipelines material. Done would mean evaluating or implementing the proposed migration, including pooled memory use, consolidation of SocketWrapper.cs, and the .NET Core 2.1 compatibility requirement.

Written by the indexing model from the issue text.