The primary goal of this change is to make it easier to support runspaces without FileSystem providers. While this is a somewhat obscure use case, it benefits the codebase as a whole by consolidating various often inconsistent permutations of

PSCommand importCommand = new PSCommand()
                .AddCommand("Import-Module")
                .AddArgument(path);

            this.ExecuteCommandAsync<PSObject>(importCommand, sendOutputToHost: false, sendErrorToHost: false).ConfigureAwait(false).GetAwaiter().GetResult();

Into a single working copy.

Summary of changes:

1. Created ImportModule(string path) method in PowerShellContextService.cs
2. Used method to load the Commands, PSReadLine, and additional modules
3. Moved the PowerShellEditorServices.Commands module to the modules folder so it could be loaded by its folder path instead of requiring a path to the .psm1 itself (this puts it in alignment with how we are doing PowerShellEditorServices.VSCode and how the Az module handles it's various sub-modules. I did this primarily because in the future when we support runspaces without FileSystem providers, we will need to use the InitialSessionState.ImportModuleFromPath() method, which only accepts folder paths and not paths to .psm1 files)
4. Updated CanGetPSReadLineProxy() test to work even though TryGetPSReadLineProxy() no longer Imports the module. We do this by exposing IsPSReadLineEnabled parameter in PowerShellContextFactory.Create() method and calling that method within CanGetPSReadLineProxy which creates an unused PowerShellContextService that Imports PSReadLine, thus loading the Microsoft.PowerShell.PSConsoleReadLine type into memory, allowing TryGetPSReadLineProxy to succeed

For reference, we are currently Importing modules from disk as needed in the following areas of the codebase:

These following module loading code has been left unmodified as they are not required modules and Import-Module is being used to determine if PSES has the stated capabilities.