Allow reasonable CLIENT commands to proceed without admin mode enabled

[mgravell]

fix #3127 fix #3128

• Historically, CLIENT was considered an admin command (because of CLIENT KILL, CLIENT PAUSE, etc)
• For most 1st party commands, we set an internal flag to say "we know what we're doing, this is fine"
• A quirk of Execute(...) < 3.x means that it didn't actively search for admin commands
• In 3.0, Execute(...) got smarter, and correctly identifies CLIENT usage
  • Now, external callers using Execute(...) would get an exception when using CLIENT
  • Additionally, AddLibraryNameSuffix uses Execute(...) internally, but uses FireAndForget - which means the error doesn't surface directly, but is reported by telemetry ([3.0.x] Known Behavior Change (Admin Command), but cannot trace back reason #3127)

Here, we add logic to detect the sub-command - for now, only necessary for Execute(...), but potentially it is versatile enough to use with other command types.

We've also done an audit of the remaining commands (#3128) - it turns out that a small number of the CLIENT ones are probably all we'd want to handle. Other combinations are still explicitly disabled; new tests assert:

• that the expected subcommands: work
• that other subcommands: do not work
• that AddLibraryNameSuffix works (which we verify by issuing a GETNAME)