change shape of alert.interval to accomodate future scheduling flavors

[pmuellr]

For alerts, we currently have a top-level interval: string property (eg, "1s" or "2m") to set the scheduling of when the alert function is run. We're 99.9% sure we'll want more in the future, the first (and maybe last) being a "cron" formatted string.

Watcher has a fairly elaborate story for scheduling options, documented here: https://www.elastic.co/guide/en/elasticsearch/reference/current/trigger-schedule.html

The full trigger "schema" for watcher is a bit overboard, but just to handle cron we'll need to do something, and it's not hard to imagine adding a few simple shortcuts like { daily: ['01:00', '11:00'] }(every day at 1am and 1pm).

Current thought is to create a top-level property schedule or sked or whatever, and move the current interval property under that. Once we add cron support, we'd allow a new cron property under schedule (presumably only supporting one at a time in the same schedule object). If we add a daily per example above, we'd add another property under schedule, etc.

This is a change to the SO, but until 7.6 ships we don't need to worry about migrations, and after 7.6 we do, so it would be nice tot have in 7.6. Same for API input/output, and for the same reason would be nice to have a future-friendly version in 7.6.

Other options include having a intervalType property, which today would be interval (by default), and then interval would be interpreted relative to that. Feels a little hacky, and also means we'd have to force-fit the value to a string, if a future type wanted something just a little richer, like the daily example above (eg, storing that as a JSON string).

Task Manager has a similar issue #51472 and it would be nice for both to use the same pattern.

[elasticmachine]

Pinging @elastic/kibana-stack-services (Team:Stack Services)