Deploying module is a bit funky until dotnet-cli gives us more control
over which libraries to build and where. Theoretically we'll be able to
package System.Management.Automation and depend on the package instead,
so Commands.Omi can be its own project entirely.
Cleaned up the Commands.Omi project.json as it had some unnecessary
cruft from where it was copied. Also removed the AssemblyInfo as it does
not matter for a new module.
Moved the Get-OmiInstance Pester test to the project's test folder so it
doesn't run with our suite of tests (as it takes a dependency on OMI).
Link to them instead so they don't get out of date. Explicitly fix the
incorrectly named file with an explicit link name. Also deploy the types
files with fixes to monad to fix shell output for various cmdlets.
Bumps monad submodule.
For the special case of having a string to insert on the buffer, switch from calling this.Insert to appending the string directly (and incrementing the count appropriately).
Need the up-to-date version so that exiting the console doesn't totally
mess up the hosting shell (Bash).
Should not depend on this package longterm, as it's
platform-specific. Tracking in https://github.com/dotnet/cli/issues/405
Removes dependency on Microsoft.Extensions.Platform.Abstractions.
Makes use of native executable from `dotnet-cli` impossible; must use
`powershell` from monad-native.
We're keeping it in the superproject for now, as it's the only build
system with a dependency on the file. However, we have to move it out of
the host because the unit tests also need to initialize the type catalog.
Andrew Schwartzmeyer