Introduce alertmanager subcommand

[martialblog]

See #111

[martialblog]

I've been tinkering a bit to include an alertmanager subcommand. I'm not 100% sure about this thing yet.
It makes sense here because it is in the Prometheus ecosystem. However, the global flags are designed for a single API endpoint, not several systems.

TODOs:

1. Flags

  -H, --hostname string    Hostname of the Prometheus server (CHECK_PROMETHEUS_HOSTNAME) (default "localhost")

Maybe need another flag for setting the Alertmanager URI, since there could be an Alertmanager cluster that needs to be checked, OR we want to include data from the Alertmanager in the current alert subcommand then we would need to check two APIs.

But then we also need other flags for the call (auth and so on), pretty much all the global flags need to be duplicated.

2. Needs Tests

[martialblog]

@RincewindsHat Do you have any thoughts?

[RincewindsHat]

hm, feels (to me) a bit like this should not be part of this plugin since check_prometheus was focussed (until now) on the prometheus software alone although the thought of potentially having multiple programs to maintain with a significant overlap instead of a bundle is not attractive either ...

So, to help getting to a decision here, I would vote against integration into check_prometheus since the UX gets rather confused (having a health subcommand for prometheus and alert which targets an entirely different program).

Possible paths into the future:

• Creating a new bundle check plugin (let's call it check_promstack for now) which integrates the logic of check_prometheus.
  For example: check_prometheus health could become check_promstack prometheus health.
• Creating a separate check_alertmanager program (and therefore potentially check_loki ...)

[martialblog]

Yeah I had similar thoughts.