Generate beta and experimental APIs, guarded by Cargo features

[swallez]

Generates all APIs, including beta and experimental. Non-stable APIs are guarded by new Cargo features beta-apis and experimental-apis (which also includes beta).

This allows applications to only have access to stable APIs (as previously) by default, and opt-in for unstable APIs, at their own risk since they can change in subsequent releases.

This also fixes the yaml-test-runner that relies on the tasks apis that were previously incorrectly marked as stable and are now experimental.

[russcam]

This is awesome @swallez, thanks for adding!

I think there's a few more changes that should be made before merging, mostly related to documentation:

1. Add beta-apis and experimental-apis to the listed features in elasticsearch\lib.rs and the root README.md, and indicate what each means e.g. less stable, subject to change, experimental-apis includes beta APIs, etc.

2. Add --all-features to tasks.docs in Makefile.toml so that documentation includes all beta and experimental APIs

3. Include wording in the generated documentation for beta and experimental APIs that indicates they are beta and experimental, respectively, and how to enable. For example, for beta, something like

   /// # Optional
   /// This requires the `beta-apis` feature to be enabled
   

   Similar to what is done for Auth components

4. Add namespace markdown files in api_generator\docs\namespaces for

   1. autoscaling
   2. eql
   3. logstash
   4. monitoring
   5. rollup
   6. searchable_snapshots
   7. text_structure

5. Don't generate the data_frame_transform_deprecated namespace

[russcam]

The whole data_frame_transform_deprecated namespace should never be generated. Looking through, I think it's the only exception.

[swallez]

Good point! Looking at the Rest spec for this, It seems we could have a rule that filters out deprecated endpoints that are not stable (this namespace is deprecated as the feature has been implemented slightly differently as stable endpoints). If it proves to require significant changes I'll hard-code the exclusion and open an issue to implement it post-7.11.

[swallez]

Thanks for the review @russcam. All good points, I'll work on this, and also on the yaml tests that keep failing ;-)

[swallez]

@russcam I have addressed all your suggestions. Can you please cross-check?

There are still some failing yaml tests that I need to investigate, but this is unrelated to those changes

[russcam]

LGTM - great effort on this PR, @swallez 🎉