[Fleet] Make var groups more generically usable

[Supplementing]

Summary

Closes https://github.com/elastic/ingest-dev/issues/7185
Related: https://github.com/elastic/ingest-dev/issues/6549
Depends on elastic/package-spec#1120

This PR makes var_groups usable everywhere, rather than just at the package root and streams level so that items can be rendered in their appropriate sections (input, etc) and take full advantage of grouping. This will unblock elastic/integrations#17495 and allow us to finalize a draft version of this integration as a poster-child that utilizes var_groups for a clean and minimal UI.

WIP integration utilizing the var_groups at the input level for grouping based on chosen auth method:

Testing instructions

If you want to manually build an integration and test, please DM me and I will send you detailed instructions or walk you through how to set up a local package-spec and point your elastic-package at it, build it, etc. Im happy to do so, but in the sake of brevity, I will skip that here.

The easiest way otherwise is to simply upload this pre-built integration that I built locally using the changes to package-spec:
okta-3.14.2.zip

Checklist

Check the PR satisfies following conditions.

Reviewers should verify this PR satisfies this list as well.

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the docker list
• This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The release_note:breaking label should be applied in these situations.
• Flaky Test Runner was used on any tests changed
• The PR description includes the appropriate Release Notes section, and the correct release_note:* label is applied per the guidelines
• Review the backport guidelines and apply applicable backport:* labels.

Identify risks

Does this PR introduce any risks? For example, consider risks like hard to test bugs, performance regression, potential of data loss.

Describe the risk, its severity, and mitigation for each identified risk. Invite stakeholders and evaluate how to proceed before merging.

• See some risk examples
• ...

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[Supplementing]

@elasticmachine merge upstream

[elasticmachine]

merge conflict between base and head

[coderabbitai]

Caution

Review failed

The head commit changed during the review from e1e7ad1 to 4a0d550.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

• 🛠️ Update Documentation: Commit on current branch
• 🛠️ Update Documentation: Create PR

Warning

Tools execution failed with the following error:

Failed to run tools: 13 INTERNAL: Received RST_STREAM with code 2 (Internal server error)

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[alaudazzi]

LGTM for the descriptions.

[juliaElastic]

LGTM

[Supplementing]

@elasticmachine merge upstream

[elasticmachine]

⏳ Build in-progress, with failures

• Buildkite Build
• Commit: 9b10f8e

Failed CI Steps

• Build Kibana Distribution
• Check Types

History

• 💔 Build #415031 failed 4a0d550
• 💔 Build #415026 failed e1e7ad1