Further automation builder refactoring.

[samwho]

Description

While working on a previous automation builder refactor I noticed that all of the trigger methods (e.g. appAction, rowCreated, etc.) took both an inputs and an outputs. The outputs were optional and only get used later if/when you call run. This confused me and made it difficult to follow the flow of information.

I've refactored this flow so that this:

await createAutomationBuilder(config)
  .cron({ cron: "* * * * *" }, { timestamp: 123456789 })
  .serverLog({ text: "Hello!" })
  .run()

Becomes this:

await createAutomationBuilder(config)
  .onCron({ cron: "* * * * *" })
  .serverLog({ text: "Hello!" })
  .test({ timestamp: 123456789 })

A few things are happening here:

1. Triggers have been renamed to start with on to make them read nicer in-situ (onCron is admittedly not the nicest example of this, things like onRowSaved is much nicer though).
2. createAutomationBuilder now returns a TriggerBuilder that you can only use to choose a trigger. Once you do, a StepBuilder<T> is returned that lets you create steps. This forces you to choose exactly 1 trigger, and types the automation based on the trigger chosen. This T is then used later in the renamed test (used to be run but test makes it more clear what API is being used) to know what output type to accept.
3. Not shown but the save method (which test calls internally) now returns an AutomationRunner<T> which allows you to call test as many times as you want without creating a new automation. This opens up some new use-cases of testing an automation multiple times without having to do gymnastic with the builder API.

So in short this new structure makes it more difficult to make mistakes, and more obvious what data is going where and when.

[qa-wolf]

QA Wolf here! As you write new code it's important that your test coverage is keeping up.
Click here to request test coverage for this PR!

[mike12345567]

LGTM - very nice!