split EC format into its own json schema file

[hl662]

This pull request refactors how the EC3.2 Format schema is defined and referenced in the JSON schema files. The main change is to move the Format definition out of ecschema-item.schema.json and into its own dedicated file, ecschema-format.schema.json, and update all references accordingly. This modularizes the schema, making it easier to maintain and reuse.

Schema modularization and reference updates:

• Removed the inline Format definition from ecschema-item.schema.json, eliminating redundancy and simplifying the main schema file.
• Added a new file, ecschema-format.schema.json, containing the full definition of the Format schema item, including all properties and constraints.
• Updated references in ecschema-item.schema.json to point to the new external Format schema at https://dev.bentley.com/json_schemas/ec/32/format# instead of the previous internal definition.

A question that might be asked: The Format has references to the base SchemaItem properties, while SchemaItem has an 'allOf' property that includes the Format. Would this case of bidirectional (or circular) references cause an issue? No, this is a common scenario with json schemas that are supported.

From json-schema rfc, the scenario above will not cause a recursion problem, only when two bidrectional schemas use $allOf would this be a problem.

[ColinKerr]

Do all the properties of a schema item type really belong in this base format definition that will be shared with FormatSets?

[hl662]

good point... I removed inheriting all of schema item's properties, reducing them to just the name (which references EC name), description and displayLabel. This way the format sets won't require schemaItemType