Improve error message for mismatched tasty versions, allow configuration of header unpickler

[bishabosha]

fixes #18427

Adds configuration ability to TastyHeaderUnpickler, why? tasty-core is intended to be a generic library, so for its error messages to suddenly assume the consumer is a scala compiler would be a breaking change, so we instead by default use a generic configuration (the old "tooling" style) and allow to plug-in a "scala compiler" configuration

Also the configuration allows us to easily test the content of error messages.

see #18828 (comment) for backporting considerations

Release Notes

Scala 3.4 improves the error message when a signature from the classpath comes from an incompatible TASTy version. It has improved readability and provides a more useful diagnostic of what a user can do to fix the problem.

Sample error 1 (reading old experimental tasty):

error while loading Tuple,
  TASTy file /scala/Tuple.tasty could not be read, failing with:
  Backward incompatible TASTy file has version 28.4-experimental-1, produced by Scala 3.3.3-RC1-NIGHTLY,
  expected stable TASTy from 28.0 to 28.3, or exactly 28.4-experimental-2.
  The source of this file should be recompiled by the same nightly or snapshot Scala 3.3 compiler.
  Usually this means that the library dependency containing this file should be updated.
  Please refer to the documentation for information on TASTy versioning:
  https://docs.scala-lang.org/scala3/reference/language-versions/binary-compatibility.html

Sample error 2 (reading newer stable scala):

error while loading Tuple,
  TASTy file /scala/Tuple.tasty could not be read, failing with:
  Forward incompatible TASTy file has version 28.3, produced by Scala 3.3.1,
  expected stable TASTy from 28.0 to 28.2.
  To read this TASTy file, use a Scala 3.3.0 compiler or newer.
  Please refer to the documentation for information on TASTy versioning:
  https://docs.scala-lang.org/scala3/reference/language-versions/binary-compatibility.html

[bishabosha]

it would be good to backport the content of the messages, however the TastyHeaderUnpickler changes would break the semantic versioning forward compatibility of tasty-core, so I propose that for a backporting in LTS line the tasty-core module is left alone, and we should duplicate the improved TastyHeaderUnpickler into the compiler module (thanks to @sjrd for the suggestion)

[sjrd]

Great tests!

[sjrd]

Let's keep the cause, here:

Suggested change

	throw IOException(message)
	throw IOException(message, e)

[bishabosha]

ClassfileParser also does not keep the cause

[sjrd]

Meh ... OK.

[sjrd]

Why RuntimeException and not Exception or NonFatal?

[bishabosha]

its what the ClassfileParser does, i.e. what TASTy unpicking used to do before we did the TASTy-first classpath change

[sjrd]

💯

[bishabosha]

@sjrd I tweaked the first line of the message because it was repetitive when combined with the additional text added in SymbolLoaders when reporting the error.

[sjrd]

@bishabosha Do you want a review by someone else? If yes can you assign them, please?

[bishabosha]

I was wondering if this might be controversial