feat(detectors): Add "make new detector" script

[thetruecpaul]

Summary

Adding a new detector is a very involved process.

This PR adds a helper script to do as much work in an automated manner as possible to make it easier to add new detectors.

Test Plan

Ran python3 scripts/create_detector.py solar_eclipse and observed that modified files looked about right.

[seer-by-sentry]

Potential bug: The `create_detector.py` script hardcodes the `MonitorIncidentType` class name, which will cause duplicate class definition errors and crash the server on import.

• Description: The create_detector.py script appends a hardcoded GroupType class definition to src/sentry/issues/grouptype.py. The class is always named MonitorIncidentType. Since this class already exists in the target file, running the script will create a duplicate class definition. This results in a Python syntax error when grouptype.py is imported, which will crash any Sentry service that depends on this module, preventing the application from starting.
• Suggested fix: Generate the GroupType class name dynamically based on the detector_name input, similar to how detector_classname is created. A new variable, like grouptype_classname, should be created from detector_name and used within the template string written to grouptype.py.
  _{severity: 0.9, confidence: 0.95}

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[asottile-sentry]

the scripts directory is meant to be tools for the build system and development environment

admittedly one off scripts like this are sort of frowned upon because they almost instantly become outdated, unused, untested, and unmaintained

it may make sense to make a separate repository where you can adequately test this and maintain it?

[thetruecpaul]

the scripts directory is meant to be tools for the build system and development environment

Moved out of the scripts directory and to the tools directory.

admittedly one off scripts like this are sort of frowned upon because they almost instantly become outdated, unused, untested, and unmaintained

Generally fair.

• I can push back a little on "unused" — this would be pretty heavily linked from our documentation (replacing half of that 25-step checklist), so it should be fairly discoverable.
• Untested, well, I could do a snapshot test to ensure that any change to outputs would be noted, but that feels like cheating to me (basically just "testing" that it works in its current state and doesn't change from current state).
• No argument on "outdated" + "unmaintained", not sure what I can say there except that I would be fairly willing to delete this if it stops working (since once it's committed it's easy to find in version history).

it may make sense to make a separate repository where you can adequately test this and maintain it?

The goal of this script is "make detector-creation as close to zero friction as possible"; having to check out a new repo and run a script cross-repo is more friction than I'd like.

[asottile-sentry]

tools is also a build system / development environment namespace too 😆

let's take a step back -- if it's hard to add one of these things why not make the actual steps to adding them simpler rather than adding a hacky script?