Resolve `RedisPipeline` Proposal Discussion Topic

Motivation:

During the discussion thread of the NIORedis SSWG proposal, there were concerns expressed over the implementation of RedisPipeline that covered the following areas:

1. Clashes with SwiftNIO concepts such as "Pipeline"
2. Misleading users on library behavior with using a Pipeline vs. a single RedisConnection
3. The implementation was "too clever" in that it allowed users to easily find themselves in "Undefined Behavior" due to lack of enough type safety in the API

However, the value in being able to control how frequently "flush" happens on a socket was discussed and considered high - so something still needs to be in place to force flushes by users.

It was decided to leave the implementation of batching commands and their responses to library users, perhaps in higher level frameworks while the library will provide said mechanism for controlling writing and flushing of commands.

Modifications:

• Add: sendCommandsImmediately bool property to RedisConnection to handle choice of flushing after each command
• Remove: RedisPipeline

Results:

Users should now have a more clear understanding on what type of control they have over the timing of when commands are actually sent over the wire, with the greater emphasis placed on RedisConnection.