Use spectre.console lib to manage ANSI escape code

[AnimalXing]

Why

Avoid using hardcoded ANSI escape codes to make it more readable.

Ticket

VUL-424

[boarnoah]

Looks nice, can you verify things still function with a native AOT build

build it similar to how we do it in CI (AFAIK PRs don't generate artifacts for u test with)

bmx/.github/workflows/publish.yml

Lines 97 to 102 in 8451532

	dotnet publish `
	/p:Version="$versionWithoutv" `
	/p:InformationalVersion="$version" `
	/p:IncludeSourceRevisionInInformationalVersion=false `
	-r $env:PLATFORM-x64 `
	-o build/x64

something like

dotnet publish -r win-x64 -o build/

Verify that things still work with that build, not expecting trouble here I think, since there is no trimming warnings / huge increase in binary size.

[AnimalXing]

@boarnoah

dotnet publish -r win-x64 -o build/

Ran this command and tested with its build. It looked fine to me. However, it had some trimming warnings just like from CI:

Warning: /home/runner/work/puppeteer-sharp/puppeteer-sharp/lib/PuppeteerSharp/BrowserFetcher.cs(177): warning IL3000: PuppeteerSharp.BrowserFetcher.GetBrowsersLocation(): 'System.Reflection.Assembly.Location.get' always returns an empty string for assemblies embedded in a single-file app. If the path to the app directory is needed, consider calling 'System.AppContext.BaseDirectory'. [D:\a\bmx\bmx\src\D2L.Bmx\D2L.Bmx.csproj] etc.

Is this something to worry about?

[boarnoah]

That is a known warning with our choice of puppeter sharp (and present prior to this PR), doesn't look relevant to the new lib you are introducing.

What we do need to verify is that the coloured text still prints as expected when invoking the native AoT build of BMX which you just built.

===

It isn't likely to be an issue in this particular case, but in the past for example we've had issues where the application works as expected when doing dotnet run.

However later when we try the native build (which has had code trimming done as part of building for Native AoT) the application no longer functions etc..

Native AoT stuff has difficulty understanding code is actually used in some cases and isn't dead code that can be trimmed, so best to always check things are functional after introducing a new library.

[AnimalXing]

It isn't likely to be an issue in this particular case, but in the past for example we've had issues where the application works as expected when doing dotnet run.

However later when we try the native build (which has had code trimming done as part of building for Native AoT) the application no longer functions etc..

Thank you for the info! Just verified that the coloured text worked as expected with the Native AoT build, both when the NO_COLOR flag was on and off.