Include pipeline processing-load snapshot in support bundles

[xd4rker]

Closes https://github.com/Graylog2/graylog-plugin-enterprise/issues/14145

Description

• The support bundle now contains pipeline-processing-load.json with the cluster-wide Processing Load (per pipeline-stage-rule, per pipeline, per rule), the same data served by GET /system/pipelines/processing-load.
• It is only included when pipeline rule debug metrics are enabled. If metrics are on but there's no usable data (no active rules / no recent traffic), the file is omitted and a note is written to errors.json.
• The Processing Load logic from ProcessingLoadResource was extracted into a ProcessingLoadBuilder so it can be reused to generate the support-bundle snapshot.

How Has This Been Tested?

Preconditions: a running Graylog with at least one pipeline connected to a stream (with rules) and some message traffic flowing through it.

1. Enable debug metrics: Go to System → Pipelines (or the Rules page) and use the debug-metrics banner to enable pipeline rule metrics. Once enabled, a "Pipeline Load (15m)" column appears on the pipeline/rules pages. After a little traffic it should show non-zero values.

2. Create a support bundle: Go to System → Logging, and in the Support Bundle section click Create Support Bundle. When it finishes, download the bundle and unzip it.

3. Verify (metrics ON): At the root of the bundle, alongside cluster.json, not inside the per-node folders, there should be a pipeline-processing-load.json. Open it and confirm "available": true with per-rule / per-pipeline load figures.

4. Verify (metrics OFF): Disable debug metrics from the Pipelines page, create and download another bundle, and confirm pipeline-processing-load.json is absent from the root.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Refactoring (non-breaking change)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have requested a documentation update.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.

[patrickmann]

Looks good