Detect and collect deprecated fields in the check

[janvhs]

This PR allows to collect and show deprecations in the checks. For more information and reasoning behind changes, have a look at the commit message. (I wish I could just tell GitHub to throw these in here)

[dottorblaster]

I like the approach catching every deprecated field, I would have aimed for something way simpler. Also, I would prefer the deprecation thing to be another validator, not modifying too much what we already had in place.

Can you fix the tests?

[gagandeepb]

1. Have you considered locking down on a more recent jsonschema meta-schema version ? I understand more recent versions have a richer validation/schema-evolution capabilities.
2. I wonder if it's interesting/feasible to express deprecation of fields using the schema-evolution capabilities of more recent versions. 🤔

[janvhs]

Yes I did, but updating the crate is not required, since it does not implement handling deprecations in future releases. As stated in the commit messages, we're going to replace this crate in future releases with boon, for it actually covers modern specs and bumping the crate to 0.20 requires updating the code either way.

[gagandeepb]

I was not suggesting to update the crate, necessarily. However, I am/was under the impression that more recent versions of the json schema spec (not the crate, but the "dialect" that a specific schema instantiation adheres to) support field-level deprecation (according to the link I shared previously). I also understand that newer versions of the jsonschema crate support newer dialects (like draft2020, draft2019, etc.) but I am not fully aware of specific dialect support/conformance limitations of the current jsonschema crate. Concretely, I was wondering :

1. If updating the schema dialect of the underlying checks DSL spec to something more recent, and
2. If marking specific fields in the DSL spec as deprecated, and
3. If handling 1 and 2 here in this repo (i.e. tlint) by making use of whichever implementation of json schema validation that appropriately conforms to the dialect that supports field-deprecation at the schema level. ...
   ... is something that is feasible/interesting to evaluate for the purposes here?

[janvhs]

json schema spec (not the crate, but the "dialect" that a specific schema instantiation adheres to) support field-level deprecation

Yeah they do and that is what is leveraged here

I am not fully aware of specific dialect support/conformance limitations of the current jsonschema crate

TLDR: they don't support this

If updating the schema dialect of the underlying checks DSL spec to something more recent, and

Sure, I can replace the link, but it won't change the fact that this implementation would still be required

If marking specific fields in the DSL spec as deprecated, and

I don't think it is wise to have multiple sources of truth

As reference af224c0

[gagandeepb]

If marking specific fields in the DSL spec as deprecated, and

I don't think it is wise to have multiple sources of truth

Indeed it is not, I agree. But how is marking specific fields in the DSL spec as deprecated an instance of multiple sources of truth? Isn't the spec supposed to be the source of truth and tlint the "verifier"/checker of an instantiation of a check against the spec?