[FEATURE] Multiple installation flows for Integrations.

[Swiddis]

Is your feature request related to a problem?
As integration setups become more complex, there's a growing need to support multiple installation flows tailored to different use cases. Presently, the setup process is streamlined for a singular installation path, which poses limitations as demands for varied setups arise. This is briefly discussed in #1444, which talks about making the installation process more flexible.

What solution would you like?
To address this, I propose enhancing the integration setup process to accommodate multiple installation flows, with a flows config option. This can be added to the config as a top-level field showing each flow:

{
  "name": "example"
  // ...
  "flows": [
    {
      "name": "Queries",
      "description": "Ingestion pipeline for logging use cases with a low querying frequency. Includes sample saved queries.",
      "required": true
    },
    {
      "name": "Dashboards",
      "description": "Optimized for high querying frequency, includes visual dashboards for additional insights."
    }
  ],
  // ...
}

These flows will be rendered in a checkbox-list on the frontend, where a user can select any number of flows to install with. When we install assets, each step can have a set of flows it's a part of (default: all flows).

{
  "name": "example"
  // ...
  "assets": {
    "savedObjects": {
      "name": "example_dashboards",
      "version": "1.0.0",
      "flows": ["Dashboards"] // Dashboards flow: installs only if the dashboards flow is selected
    },
    "queries": [
      {
        "name": "create_table", // No flows: always installs
        "version": "1.0.0",
        "language": "sql"
      },
      {
        "name": "saved_queries",
        "version": "1.0.0",
        "language": "sql",
        "flows": ["Queries"] // Queries flow: installs only if queries selected (equivalent to no flows if queries is required)
      },
      {
        "name": "create_mv",
        "version": "1.0.0",
        "language": "sql",
        "flows": ["Dashboards"]
      }
    ]
  },
  // ...
}

This refactoring is equally applicable if #1444 is implemented.

What alternatives have you considered?

Separate integrations could be made for each flow. This avoids the need for the feature, but complicates the selection process when a user is onboarding.

Do you have any additional context?

N/A