Initial support for remote reporters

[WojciechMazur]

This PR aims to provide a capability of collecting crash reports using a remote reporter.

We introduce a new project telemetry-interfaces allowing to define a structured API for connecting between Metals components (MetalsLspService, ScalaPresentationCompiler) and a HTTP REST server aggregating the reports. API is defined using Java along with provided Gson codecs to ensure correct serialisation. Separate model would allow evolve the schema in the future.

Initial prototype involved usage of Smithy4s for generation a Scala idiomatic model and to ensure usage of the same schema between metals client and remote server. However, this approach would introduce number of new dependencies to project, and would require to cross publish for each of the targets. The original smithy schema is temporary still available in the branch for a quick lookup of the model.

New ReportContext implementations:

• MirrorReportContext - duplexing of reporting, allowing to send reports to multiple reporters, eg. to file using StdReportContext and remotly
• RemoteTelemetryReportContext - a reporter using HTTP client to communicate with server aggregating reports

A dedicated server for remote telemetry was created in the separate repository. Temporaly it was installed in the Scala Open Community Build environment and available under https://scala3.westeurope.cloudapp.azure.com/telemetry

TODO:

• - inspect the telemetry interfaces model, which information is redundant or missing to get enough context about the errors
• - set up dedicated environment for the remote server
• - how to propagate remote reporter config to ScalaPresnationCompiler?
• - decide should Report.text should be available in the Remot Reports - the local work with ScalaPresentationComiler suggests it can contain a full source code of failing to compile sources
  #solved:
  text contains important context required to reproduce issues. To allow for keeping orignal source code we introduce a SourceCodeSanitizer - it would try to parse sources using Scalameta/Dotty parser and replace all names with stable obfuscated symbols not containing any domain/author/organization information. Same applies to String literals which would be redacted out. In case if parsing/transformation of source code ast would fail no original sources would be reported.
• - how to enable/disable at user level, how to deal with secure environemts (limited access to Internet)
  #solved:
  UserConfiguration was updated to contain the telemetryLevel specified by the user, can be set using client config (Allow to pass telemetry level in user config metals-vscode#1441) or via Metals properties -D-Dmetals.telemetry-level={off, crash, error, all}

[WojciechMazur]

For the review of model the not-yet removed smithy schema can be used. The Java API has been generated based on that.

In perfect world we would be able to generate Java code from this schema, but there is no smithy codegen available for Java (only Kotlin and Scala has implemented codegens)

[kasiaMarek]

Suggested change

	if (fillInLength < 0) prefix.tail.take(-fillInLength)
	if (fillInLength < 0) prefix.tail.dropRight(-fillInLength)

Also if someone has like 100 names and uses new three letter one, this will produce a 4 letter substitution.

[tgodzik]

@rochala Will this not be a problem for the compiler?

[rochala]

This will be a problem and has to be changed. We can't add any Scala dependencies directly to the compiler. This can be easily changed tho, so remote report context is implemented in metals, and passed to the PC via implicit. We don't need to implement it directly in the PC