V3 pre-merge; all the early bits, for V2

[mgravell]

This is a very large part of #3014, dragged down into v2 - pretty much as much as possible without making the v3 client changes

• bring the eng build tools down, which has FastHash -> AsciiHash
• bring RESPite down, in the current RespReader state from v3
• bring the updated toy server down, entirely migrated to RESPite
• make the minimal client changes to switch to AsciiHash an enum parsing instead of FastHash parsing
• bring down the requests LCS changes and the missing RedisType.VectorSet

Purposes of this PR:

• minimize the size of the V3 PR
• minimize the size of the V2 vs V3 delta going forward
• bring the toy-server down to V2: the V3 core is a lot more stable for the server, and enables MULTI/EXEC (which cannot be easily implemented on the V2 core)

[NickCraver]

I left comments for 3.0 (holy bytes batman), but the more I look at this the more I think we should not backport a change this large with 2.x, and instead just get 3.x previews going. Let's discuss on call and see where y'all are at, just which way I'm leaning after assessing the diff.

[NickCraver]

Suggest using System.CodeDom.Compiler.IndentedTextWriter here - handy for cleaner generation downstream

[mgravell]

literally never heard of it before; took a look... I'm not sold; there's no fluent API, so I have to either do

tw.Write("// ");
tw.Write(GetType().Name);
tw.Write(" v");
tw.Write(GetVersion());
tw.WriteLine();

or I need to use interpolated strings

tw.WriteLine($"// {GetType().Name} v{GetVersion()}");

Are you proposing this latter? It is a bit more allocatey, but I guess it doesn't kill anyone...

[mgravell]

@NickCraver I think I can summarize your feedback into a few buckets:

• #if NET* - yep, simplified; let's do this!
• a few hacky things around the analyzer project
  • tidy how referencing the analyzer works
  • do better about fromBytes
  • is the pre-built indented writer; I'm not sure about this one, seems very messy and low gain for the effort
• a few questions over the key-events API: already considered and implemented as part of the existing shipped design
• some confusion over what APIs we are adding: I suspect I confused you by refactoring the PublicAPI files, but short version: "we're not" - the only API additions are trivial and limited to the LCS/VectorSet ones Philo requested; everything else is just churn noise, so I don't think this is a concern
• a doubt over the size of the FastHash -> AsciiHash migration

Is that fair? I think I've resolved everything except that last AsciiHash one and the indented writer; I'd prefer to punt on the writer for now, and personally I'm more than comfortable with the FastHash -> AsciiHash. Thoughts?