Improve Windows installation experience

[perlun]

Our current download instructions at https://perlang.org/download/ suggests the usage of Git Bash on Windows. Well, too bad it doesn't really work at all after installation in that shell though. 😒

Interestingly enough, it works pretty fine in a regular cmd.exe window after installation though, so I think it would be pretty much enough at this stage to:

• Improve the instructions on the web page to make this a "known limitation" of the current setup.
• Detect the fact that input is redirected and never even try to read keys from the console in that case. (If we really want to be kind, we could suggest the usage of cmd.exe on Windows instead of Git Bash.)

Worth mentioning is that things seem to work nicely in WSL, though.

$ $HOME/.perlang/nightly/bin/perlang
Perlang Interactive REPL Console (0.1.0+b67d337)
> Unhandled exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
 ---> System.InvalidOperationException: Cannot read keys when either application does not have a console or when console input has been redirected. Try Console.Read.
   at System.ConsolePal.ReadKey(Boolean intercept)
   at System.ReadLine.GetText(KeyHandler keyHandler)
   at System.ReadLine.Read(String prompt, String default)
   at Perlang.ConsoleApp.Program.RunPrompt()
   at Perlang.ConsoleApp.Program.<>c.<Main>b__6_0(ParseResult parseResult, IConsole console)
   --- End of inner exception stack trace ---
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor, Boolean wrapExceptions)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.Delegate.DynamicInvokeImpl(Object[] args)
   at System.Delegate.DynamicInvoke(Object[] args)
   at System.CommandLine.Invocation.ModelBindingCommandHandler.InvokeAsync(InvocationContext context)
   at System.CommandLine.Invocation.InvocationPipeline.<>c__DisplayClass4_0.<<BuildInvocationChain>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseParseErrorReporting>b__19_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass14_0.<<UseHelp>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass22_0.<<UseVersionOption>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass21_0.<<UseTypoCorrections>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseSuggestDirective>b__20_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseParseDirective>b__18_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseDebugDirective>b__10_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<RegisterWithDotnetSuggest>b__9_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass12_0.<<UseExceptionHandler>b__0>d.MoveNext()

[perlun]

Reading https://stackoverflow.com/questions/46901071/readkey-not-working-in-net-core/46952718 and subsequently https://github.com/MicrosoftDocs/azure-docs/issues/30917 made me realize there is actually a workaround for this which is quite simple. Quoting https://github.com/MicrosoftDocs/azure-docs/issues/30917#issuecomment-492173859:

@YaraZakaria There seems to be a couple of inconsistencies when running interactive windows programs that use native windows API in mintty (powers git-bash).

If you are running the dotnet command in CMD or PowerShell, you shouldn't see this problem.

For git-bash, you will have to run to run the dotnet command prefixed with winpty

winpty dotnet BasicSendReceiveQuickStart.dll -ConnectionString "myConnectionString" -QueueName "myQueueName"

So, what we should do:

1. Detect that we are running on Windows when "application does not have a console or when console input has been redirected".
2. Show a friendly error message suggesting that the command should be prepended with winpty.

Once this is done, we should be able to remove the warning from https://perlang.org/download 🎉

[perlun]

Confirmed that winpty is available in Git Bash and that prepending perlang with winpty works as expected: