Use JSON schemas for JSON CRAC import

[bqth29]

Please check if the PR fulfills these requirements

• The commit message follows our guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

Does this PR already have an issue describing the problem?
Fixes #1165
Fixes #1171
Fixes #1074

What kind of change does this PR introduce?

What is the current behavior?

What is the new behavior (if this is a feature change)?

Does this PR introduce a breaking change or deprecate an API?

• Yes
• No

If yes, please check if the following requirements are fulfilled

• The Breaking Change or Deprecated label has been added
• The migration steps are described in the following section

What changes might users need to make in their application due to this PR? (migration steps)

Other information:
This PR is the first step of a broader work of implementing a thorough and coherent Creation Context for JSON CRAC as presented in #1083 and #1098.

When importing a JSON CRAC file, there are two possible types of errors that can occur:

1. stuctural errors because of missing mandatory fields, unknown fields or incoherent fields with respect to a fixed version that must lead the importer to crash
2. business errors because of data that make no sense in a business point of view even though their aspect seems legit on a structural point of view (ex: a curative FlowCNEC without a contingency)

The latter are the types of erros that must be added to a Creation Context. Thanks to the JSON schemas, the JSON CRAC deserializer is called only is we are sure that the input file matches an accepted pattern for a JSON CRAC file. Then, we can simply handle minor business errors in the deserializer and add them to the Creation Context.

This is better than what is currently done because a structural error in the provided JSON files leads the importer to crash even though the JSON importer asserted that the format was right. This prevents for instance users to define another type of JSON Crac.

[pet-mit]

discussed with @phiedw
let's try reading the "version" field in the crac and then fetching the corresponding json schema. this has 3 advantages :

• you won't need to fetch all schema files anymore
• we do one validation per file
• the error messages will be specific for the crac version indicated by the user

To read the crac version, either do it manually by parsing the json first before validating it, or create a new validation schema that only read the version, and call it before the other version-specific schema