not having a bridge is no excuse not to complete something; if the bridge is unavailable, complete things on the shared manager (which will defer to the thread-pool if disposed)

code; the question is whether we guarantee that the completion has
*already run* or not - we don't want to do this on the processor, as
anything that involves changing Task status can lead to thread theft, so
it is done via the custom thread pool; the fix here is simply to check
that the task *becomes* cancelled (in a timely fashion), rather than that
the task *is* cancelled; anyone using "await" or ".Wait()" ".Result" will
observe that *anyway*; also tidied up some efficiency code to reduce exception
allocations in this scenario

This now throws early for an invalid call, rather than a currently confusing server message to users (see #724 fo details).

This is more consitent with our commands, enums, and redis docs themseleves.

fixed incorrect expectation for #900 - or... should it resolve at parse time? (decisions, decisions)

rework everything to use CommandBytes rather than having tons of byte[] all over the place; move Execute command checking earlier, adding ArgCount concept to allow full check

be evil, and make use of the innards of RedisValue to store array data (ref and count) when TypedRedisValue is multi-bulk

# Conflicts:
#	StackExchange.Redis.Server/RedisServer.cs
#	StackExchange.Redis.Server/RespServer.cs