schemas: add WORK-IN-PROGRESS placeholders, don't mention patch numbers, update terminology

[handrews]

I'd like to merge this and address it in the build scripts rather than resuming publication of schemas with absent dates and misleading patch release guidance.

• Replace all dates with WORK-IN-PROGRESS
• Append a date segement (as WORK-IN-PROGRESS) where missing
• Adjust refs and other fields to WORK-IN-PROGRESS
• Remove mention of specific patch releases
• Use capital-D Document and Description according to new rules

[handrews]

@ralfhandl As I noted in my comments on #4139, I am aware that this is more complex. I also noted there (and apparently forgot to note here, for which I apologize- if you read this first it was no doubt confusing) that it's probably fine to just change all of the dates at once for now. Certainly the first time we publish things we'll have changes to schema and need to set initial dates on dialect/base and meta/base. We'll also need to update base-schema to point to the new schema every time any of the other three are iterated.

So for now, a global search-and-replace is fine. We can then refine it. The rules are fairly straightforward:

• Changes to anything require a change in base-schema
• Changes to meta-base require a change to dialect-base

I think this will be easier to manage once we fix the branching. We need a schema-dev branch analogous to the dev branch so that we can manage schemas in parallel. They can't just be on the dev branch because they don't change at the same rate. But particularly with 3.1+, it's best that we be able to make a series of changes and decide when to publish to main, just like we do with the spec. It's just that the threshold for publishing should be much lower.

But doing this will make it easier to manage which of the various schema dates need updating.

Keep in mind also that you can search/replace schema/WORK-IN-PROGRESS, schema-base/WORK-IN-PROGRESS dialect/base/WORK-IN-PROGRESS, and meta/base/WORK-IN-PROGRESS separately, as none of them are substrings of each other.

Questions answered

[ralfhandl]

If we remove the ready-to-use id or $id from the YAML files, we should add a link to https://spec.openapis.org/ to each of the README.md files.

[handrews]

I realized that we can't both host a schema ending in /base and have a directory of schemas like /base/2024-10-18. Absent any better idea, I just replaced base with WORK-IN-PROGRESS instead of appending it.

Note that the vocabulary URI (not to be confused with the vocabulary metaschema URI) does not get a date as it is about the semantics, which aren't going to change within a minor release line even if we correct or add commentary to the corresponding metaschema.

It's not ideal to have this base alongside 2024-10-18, and I'm open to other date-including patterns.

[ralfhandl]

Resolved conflicts and aligned the two README.md files.