ssi: add processor tags and preserve_original_event on failure (2/4) - #20573

ssi: add processor tags and preserve_original_event on failure (2/4)

Tag every ingest pipeline processor across 51 SSI-owned packages
(eset_protect through sentinel_one_cloud_funnel), so that failure
telemetry can attribute an error to the step that produced it rather
than collapsing same-type processors into one bucket. All 24011
processors across the 341 pipeline files now carry a tag, 13136 of them
newly, including those nested inside `on_failure` handlers and
`foreach` bodies, and those in the pipeline-level `on_failure` block.

Every processor gets a tag of the form `<descriptive_name>_<8hex>`,
where the 8-hex suffix is a content hash over the processor body and
its enclosing context. Identical constructs in identical surroundings
produce the same hash in every package, giving each tag a stable global
identity in failure telemetry. Tags that already carried a hash are
left byte-identical -- 1293 of them, in sentinel_one, m365_defender and
okta, which shipped tags before this series; a hash is only meaningful
relative to the generator that produced it, so re-hashing a published
tag churns a value consumers may key off. Those three packages therefore
keep the earlier suffix format. Tags that would have said nothing
(`script_<hash>`, `fail_<hash>`) are seeded from the processor's
description, name, message or preceding comment, and tags whose leading
word named the wrong action (`set_...` on an append) are corrected.

Add preserve_original_event to pipeline-level on_failure handlers that
were missing it, ensuring the raw payload is retained when a pipeline
error document is indexed. Thirteen of the 51 packages needed it.

Pipeline-level on_failure error.message appenders use the conventional
four-line template so that the processor tag is captured in the error
record: processor type, a conditional tag line, and the failure
message. The template uses a folded block scalar (`value: >-`) rather
than a literal block (`value: |-`). Long `if:` conditions in
google_workspace/admin and sentinel_one_cloud_funnel pipelines are
reformatted using `if: >-` for readability.

Seventeen processors across nine packages were exact duplicates of an
earlier sibling and could never have any effect; they are removed
rather than given a disambiguating tag. Two further fixes ride along,
each in the affected package's changelog:

  - gcp, jamf_protect: six pipeline-level on_failure handlers set
    error.message instead of appending, discarding what processor-level
    handlers recorded. Only jamf_protect's telemetry_legacy audit
    pipeline records any today, but the pattern is wrong in all six.
    error.message is now an array on failed documents.

These are enhancements, so the packages take a minor version bump.
sailpoint_identity_sc keeps its 2.0.0-next prerelease and takes its
changelog entry there instead.

Updates #20558