[Refactor proposal] streamline filtering of detection types across all code and Jinja templates

[cmcginley-splunk]

Casey:

In the jinja2 template we determine detections to include as:

{% if (detection.type == 'TTP' or detection.type == 'Anomaly' or detection.type == 'Hunting' or detection.type == 'Correlation') %}

This works in practice, but I'm concerned with the burden of having to track this filtering logic in multiple places in potentially inconsistent ways. If we added a new detection type, and neglected to change it here, we might silently be excluding new detections from our build

Eric:

We do this type of thing A LOT, including in all the Pydantic Validations.
The initial idea here is to treat Detections differently than Baselines, as you can see in the Jinja2 templates:
https://github.com/splunk/contentctl/blob/390c3727bf83b5af3e50e4ed4434b542a7d8629f/contentctl/output/templates/savedsearches_detections.j2

contentctl/contentctl/output/templates/savedsearches_baselines.j2

Line 6 in 390c372

 {% if (detection.type == 'Baseline') %} 

This comes from a time when a Baseline and a Detection were defined as the same object, I believe.

Let's talk more about how to actually fix this at scale. I also don't like how Baselines and Detections have SO MANY fields in common, but they are totally different objects (that only inherity from SecurityContentObject).