2.0 Beta release checklist items

[Manishearth]

These are all the items from the release checklist and the graduation checklist that I think matter for ICU4X 2.0 beta in a way that cannot be resolved day-of release:

• The crate should be almost fully documented
  • Almost every exported function should have docs coverage
  • There should be a crate-level example that illustrates a common use case for the component with the heading # Examples
  • All options and conditional code paths should have a corresponding docs test with the heading # Examples
• The data structs should fully follow ZeroVec style
  • Deserialization should not have a "zero-copy violation" in the make-testdata test
  • Constructors should avoid allocating memory in the common case
  • Opaque blobs of data should be avoided if possible (instead use VarZeroVec, ZeroMap, etc.)
  • Data structs should not be panicky to load/deserialize and conform to data_safety.md
  • If any data structs use a large or unbounded number of data marker attributes, they are implemented in a way that reduces stack space, file size, and construction time, such as by having only a single variable-length field
• The component should encourage i18n best practices
  • The component should produce correct results in all locales as generated by icu4x-datagen
  • Where applicable, the component should be consistent with ECMA-402 and UTS#35
  • Any gaps in i18n quality should be fixed, or, if that is not possible, they should have tracking issues and a concrete, resourced path forward. The intent is to not ship components with known i18n correctness problems and no plan to fix them in an upcoming release
  • The API design should be informally reviewed by someone else, who may be an ICU4X team member
• There should be a completed changelog
• We should go through ffi/capi/tests/missing_apis.txt and make note of glaring gaps, and ensure there is a clear path to filling them before the release.

These items need not be completed perfectly, as long as they are completed to some extent.

cc @sffc @robertbastian

[Manishearth]

We're done here for beta. missing_apis is fine for beta, we plan to fix FFI for the release.

[sffc]

Pre-release checklist:

• Verify that the milestone and checklist are complete
• Verify with component owners that they're ready for release
• Take a bird-eye view at:
  • READMEs
  • Documentation
  • Coverage
  • Performance / Memory / Size benchmarks
  • Cargo.toml files
    • All dependencies from the workspace should use workspace = true rather than their version number or path
    • Cargo.toml files need to specify versions for each non-workspace entry in dependencies, or use workspace = true.
    • Ensure that any new packages have version number 0.0.0, this will making bumping during the release easier.
    • Ensure that the Cargo.toml file includes a set of fields consistent with other ICU4X packages.
      • These should mostly use workspace inheritance
• Run cargo +nightly fmt -- --config=format_code_in_doc_comments=true --config=doc_comment_code_block_width=80 to prettify our docs Format docs for 2.0.0-beta1 release #5863
• Run cargo update for each Cargo.lock file to update our CI to freshest dependencies Bump all ICU4X crates to 2.0.0-beta1 #5862
• Go through ffi/capi/tests/missing_apis.txt and verify that it is empty. If it is not, component owners should either add FFI APIs, add rust_link annotations, or allowlist the relevant APIs as having been punted to the future
• Verify that ffi/capi depends on a released (not Git) version of Diplomat. Get it published (ask manishearth or sffc) otherwise.
• Get all contributors to complete the changelog (see below)
• Draft the text for the GitHub release. This text will be sent to GitHub subscribers and can also be used for the mailing list email and blog post.
• Prepare a PR to update tutorials using the upcoming release. The PR should pass cargo make test-tutorials-local, but can fail cargo make test-tutorials-cratesio prior to release

[sffc]

"Take a bird-eye view at benchmarks" => #5865

"Take a bird-eye view at READMES" => there are some warnings like this:

Automatically generating components/properties/README.md 
warning: Could not resolve definition of `crate::CodePointSetData`.
warning: Could not resolve definition of `crate::CodePointMapData`.

But the output just drops the links. I feel like these have probably been there for a long time. I'm inclined to ignore.

All dependencies from the workspace should use workspace = true rather than their version number or path

#5866

[sffc]

cargo make test-tutorials-cratesio seems to work.

That is the last item in the worksheet.