rename `schema_file_format` to `json_schema`

[cdisselkoen]

Description of changes

A number of pedestrian changes in this PR:

• Rename the schema_file_format module to json_schema, to make clearer it describes the JSON format specifically. This mirrors the existing module human_schema.
• Rename the json_schema::SchemaFragment type to json_schema::Fragment.
• Rename the json_schema::SchemaType type to json_schema::Type.
  • Previously we had Type in the root namespace, SchemaType in the root namespace, and human_schema::Type. Now we have Type in the root namespace, json_schema::Type, and human_schema::Type.
  • Also rename try_schema_type_into_validator_type() to try_jsonschema_type_into_validator_type().
• Rename the json_schema::SchemaTypeVariant type to json_schema::TypeVariant.
• Don't use items from json_schema in the root namespace of cedar_policy_validator. Also avoid useing these items in our own internal submodules outside of the json_schema module. This has the effect of clarifying where JSON structures are being used. For some important examples:
  • In human_schema/to_json_schema.rs, one function signature is now Schema -> json_schema::Fragment instead of Schema -> SchemaFragment.
  • In schema.rs, instead of constructing a ValidatorSchemaFragment from a SchemaFragment, we now construct a ValidatorSchemaFragment from a json_schema::Fragment.
  • In namespace_def.rs, instead of constructing a ValidatorNamespaceDef from a NamespaceDefinition, we now construct a ValidatorNamespaceDef from a json_schema::NamespaceDefinition.
  • Also in namespace_def.rs, instead of converting SchemaTypes to Types, we convert json_schema::Types to Types.
  • Outside of the json_schema module itself, this further distinguishes json_schema's EntityType from core::ast::EntityType which is frequently used in cedar_policy_validator.
• Export Path in human_schema directly, as opposed to just living in human_schema::ast.
• In tests, prefer to use json_schema::SchemaFragment::from_json_value() and similar, over direct calls to serde_json.
• No changes to the public (cedar_policy) API.

Issue #, if available

Checklist for requesting a review

The change in this PR is (choose one, and delete the other options):

• [x] A change "invisible" to users (e.g., documentation, changes to "internal" crates like cedar-policy-core, cedar-validator, etc.)

I confirm that this PR (choose one, and delete the other options):

• [x] Does not update the CHANGELOG because my change does not significantly impact released code.

I confirm that cedar-spec (choose one, and delete the other options):

• [x] Requires updates, and I have made / will make these updates myself. (Please include in your description a timeline or link to the relevant PR in cedar-spec, and how you have tested that your updates are correct.)

[cdisselkoen]

Was thinking of that too, but that can be a separate PR