Enable client-side toolshed commands

[ElectroJr]

trafficstars

About

This PR allows clients to execute Toolshed commands via the normal shell/IConsoleHost. The majority of this PR involves deduplicating some code from ServerConsoleHost and ClientConsoleHost and moving it into shared code. This PR also moves almost all Toolshed related code out of the ConsoleHost, in favour of just having ToolshedManager use IConsoleHost.RegisterCommand to register relevant Toolshed commands.

Due to some changes around command permissions (moving IConGroupController to shared) this requires a content PR

Sandboxing / Is it safe?

AFAIK client-side Toolshed commands were just disabled in case there were sandboxing issues, seeing as it uses some lambda expressions & reflection and no other maintainer had gone over it. AFAIK it seems safe to enable. The main code that deals with reflection & lambda expressions is GetConcreteMethodInternal() and GetImplementationInternal() in ToolshedCommandImplementor. The former tries to get a MethodInfo for a (possibly generic) method defined in a ToolshedCommand, while the latter complies a lambda expression that calls that method with arguments that were parsed from the command string or came from the output of a previous command.

Toolshed commands are currently "disabled" for clients due to some #if !CLIENT_SCRIPTING blocks that prevent access to ToolshedManager.DefaultEnviroment, and because the client's console host doesn't recognise Toolshed commands. However, AFAICT they're not actually truly disabled for content/clients as they can just create their own ToolshedEnvironment & IInvocationContext and can then just execute Toolshed commands directly via ToolhsedManager. I.e., this PR just enables client-side Toolshed commands by default in the engine, but content could already have effectively enabled them by manually registering the commands.