Add support for CLI-formatted errors and allow for dead code elimination

[fheinecke]

The current DebugReport has a couple of issues:

• The error message fields are HTML-escaped. This makes them difficult to read in a CLI context, especially anywhere we do something like trace.Errorf("some error message: %q", "some relevant information"). Here's an example of what a debug report can currently produce:

   ERROR REPORT:
   Original Error: *errors.errorString inner error "quoted value"
   Fields:
   key: "<>&'azAZ1,./ string field with special characters
   Stack Trace:
   	/Users/fredheinecke/trace/trace_test.go:425 github.com/gravitational/trace.TestDebugReportMatchesTemplate
   	/opt/homebrew/Cellar/go/1.23.5/libexec/src/testing/testing.go:1690 testing.tRunner
   	/opt/homebrew/Cellar/go/1.23.5/libexec/src/runtime/asm_arm64.s:1223 runtime.goexit
   User Message: some multiline user error
   	line 2
   	outer error
   		middle error struct { key1 string; key2 bool; key3 int }{key1:"val 1", key2:true, key3:123456}
   			inner error "quoted value"
  

  Error messages "bubbled up" through many layers in Teleport can have significantly more escaping, making logs painful to read.

• Using the golang templating removes the possibility of dead code elimination, because it calls reflect.MethodByName.

This PR adds a new interface (for backwards compatibility), which adds separate HTML and CLI debug report functions. The HTML versions produce identical error messages as the (now depreciated) DebugReport() functions. The CLI versions produce messages in the same format, but without any escaping.

The PR also changes the underlying templating implementation to use a string builder rather than a template. This makes the code slightly harder to read, but removes the reflection dependency. While this is unlikely to make any different in Teleport product binaries, it should reduce the binary size of some of our internal tools. It should have a positive impact on the ~600 non-Gravitational consumers of this library as well.

[rosstimothy]

As discussed offline, I don't think this is the right approach to solving the problem.

[espadolini]

I believe this was superseded by #118