fix: side effects in tag references

[baywet]

This fixes multiple issues:

• tag references are not like other component references. The tag in the operation is just a string. We had a lot of special casing, etc...
• lot of side effects where we were impacting the source tag by assigning things to the reference. As discussed in v2 - security - correct the proxy design implementation #1998
• fixes references not being resolvable in a lot of contexts due to a missing document reference.

We should still break the inheritance, and use a base abstract class as well.

[sonarqubecloud]

Quality Gate failed

Failed conditions
75.9% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud

[darrelmiller]

I'm not sure I agree with this. Tag references are very similar to using $id to reference a Schema, where the target object is implicitly created. I agree that it was a bit of a stretch when $refs could only use locators, but now that we need to support $refs as identifiers, I think there is a strong parallel.

[baywet]

The previous model results in tons of side effects.
I get the fact that we want to facilitate the readers life, but anybody making changes and not paying attention to the underlying specification is in for troubles.

A simple example:

• parse a description with tags
• on an operation, grab a tag
• add an extension to it
• you've now updated that tag for the whole document.

Same goes for the description, the tag name etc...