Link to troubleshooting guide from exception messages

[Marcono1234]

⚠️ Maybe wait with merging this until #2323 is merged.

Purpose

Adds troubleshooting guide links to some exception messages; improves unit tests

Description

As shortly discussed in #1219 (comment) (TypeToken validation is not implemented here though) adding troubleshooting guide links to exception messages hopefully makes it easier for users to understand what the exception means and how to solve the issue.

This approach again uses custom HTML anchors in a Markdown document even though we had bad experience with this before (#2286), but it appears using only lowercase IDs is supported by GitHub (though possibly not officially, see open question https://github.com/orgs/community/discussions/50962). The custom HTML anchors allow us to produce short stable links.

Open questions:

• Possibly we could also consider including the troubleshooting section ID (e.g. "T1") in the troubleshooting guide headers, but that might become confusing if we decide to reorder, remove or merge sections in the future and the section IDs are then not in order anymore. What is your opinion?
• Currently for all MalformedJsonExceptions it refers to the troubleshooting guide; maybe we should reduce this only to specific variants?

Checklist

• New code follows the Google Java Style Guide
• If necessary, new public API validates arguments, for example rejects null
• New public API has Javadoc
  • Javadoc uses @since $next-version$
    ($next-version$ is a special placeholder which is automatically replaced during release)
• If necessary, new unit tests have been added
  • Assertions in unit tests use Truth, see existing tests
  • No JUnit 3 features are used (such as extending class TestCase)
  • If this pull request fixes a bug, a new test was added for a situation which failed previously and is now fixed
• mvn clean verify javadoc:jar passes without errors

[Marcono1234]

Or maybe instead of the anchors t1, t2, ... it would be better to use more expressive ones, such as unexpected-structure, class-unsupported, .... What do you think?

Edit: Have changed this now; feedback regarding the anchor names is appreciated!

[eamonnmcmanus]

This looks great! I'm sure it will be very helpful for users.
I'm holding off on merging as requested.

[Marcono1234]

I'm holding off on merging as requested.

Or could you please merge it now already? My intention was to avoid conflicts for #2323, however it looks like that has already conflicts with master now, and also it targets the strictness branch, so it might take some time until it is finally merged to master.