Core schemas 1p7p0

[braingram]

Update core schemas:

• ndarray to use new datatype schema
• integer to use new ndarray schema

This is the start of 1.7.0 core schemas which triggers:

• a new 1.7.0 manifest
• a new structure for handling development of a new version of the core schemas (1.7.0)

The goal of the new structure is to allow package testing (to see what updates are required to support the new core schemas) without making it too easy for a user to write files using the development schemas. We want to make writing files with these development schemas difficult because there is no expectation that the development schemas will be stable (put another way, the development schemas may change without a version change).

To accomplish this this PR:

• uses a new environment variable ASDF_UNSTABLE_CORE_SCHEMAS to flag registration of the new development schemas
• splits asdf-standard resources into "stable" and "unstable" sub-directories. This results in a very unhelpful diff for this PR. The directory creation is in commit d3b2890 so it may be helpful to view this diff instead of the files changed above.
• adds a new private _versioning module which can be used by asdf to get which stable and dev versions of the core schemas are in this version of the asdf-standard module.
• adds a new public exceptions submodule with a new warning type UnstabeCoreSchemasWarning which will be issued when ASDF_UNSTABLE_CORE_SCHEMAS is set and the dev schemas are returned as "supported".

asdf-format/asdf#1962 extends this PR allowing asdf to use the ASDF_UNSTABLE_CORE_SCHEMAS to:

• conditionally register a core extension for the unstable (1.7.0) schemas
• switch to the unstable version as the default version
• runs with this flag enabled during "devdeps" testing

The above process makes it difficult for a user to write out a file using the unstable schemas (they must define the environment variable). I'm also considering options for creating warnings when writing files with the dev version (although this may prove more harmful than helpful and get in the way of many unit tests).

If we adopt the above approach, at some point in the future we'll want to release the "unstable" schemas by:

• moving them into "stable"
• moving the dev version to stable in _versioning

This will trigger asdf to start using the now new "stable" version as the default.

[braingram]

From offline discussion @zacharyburnett suggested unstable instead of dev. unstable is more informative than dev so I'm also going to look at updating this and the asdf PR to use unstable and ASDF_UNSTABLE_CORE_SCHEMAS.

[braingram]

During the dev->unstable rename I noticed a lack of CI job here testing the unstable schemas. I updated this PR to add a py313-unstable job that sets ASDF_UNSTABLE_CORE_SCHEMAS:
https://github.com/asdf-format/asdf-standard/actions/runs/17835000435/job/50709903310?pr=479

[zacharyburnett]

this LGTM