Fix clear last line on Windows Terminal Issue again (#203).

[tig]

PR Summary

• Fixes #203 for real.
• Fixes #208
  • Adds the following diagnostics features:
  • If either -Debug or -Verbose parameters are set the OCGV status bar will display both the ConsoleGuiTools module version and the Terminal.Gui library version.
  • If the -UseNetDriver parameter is set, Application.UseConsoleDriver will be set to true, forcing Terminal.Gui to use NetDriver instead of CursesDriver (Linux) or WindowsDriver (Windows).
• Turns off the bogus -Verbose logging (Fixes #192).
• Upgrades to dotnet 7.0 since Terminal.Gui uses 7.0
• ./Build.ps1 now
  • Auto increments the module verison build (major.minor.patch.build)
  • Publishes the built module to a local PSRepository named local for local dev of downstream modules  

    PR Context

There are cases where the previous fix to #203 (#205) didn't work.

There are a lot of interactions between the platform (Windows v. Linux), terminal (e.g. Windows Terminal vs. VS Code's terminal), and Terminal.Gui's various drivers that conflict and are confusing. In addition, it's challenging to understand what code is actaully loaded when running a CmdLet. Hence the new diagnostics and ability to force NetDriver.

Note, with Terminal.Gui v2, the need for -UseNetDriver goes away because the new ConfigurationManager lets users set options like that globally, per-user, or on an app-by-app basis.

[tig]

Marked as draft until Terminal.Gui v1.14.x gets released.

[tig]

@andyleejordan I think this is ready now.

[andyleejordan]

@tig reviewing now! Sorry, I was out sick for a while which pushed everything back on my schedule.

[andyleejordan]

Ok awesome, I built and tested locally and can't repro #203 with this, yay! However, when I tested with -UseNetDriver I ended up with a blank line that wouldn't go away:

Is that a known issue with the .NET driver? I don't think I'm going to consider it a blocker since the default (with the Windows driver) worked fine.