Make options for actions reusable

[eibens]

Currently, there is a lot of duplication in regards to option type definitions.

Advantages:

• Code reduction for action dependencies.
• Code reduction for actions map, possibly even automatic wiring.
• Code reduction for loggers and easier transition to event-based logging (#53).

Disadvantages

• Tighter coupling. Right now the actions are pretty much agnostic to everything else, since each defines its own interface.
• Separating dependencies and 'normal' options introduces knowledge about the application structure into the actions. This is not too bad, since the interface of each action is already really specific.
• An additional module and local dependency per action. In order to keep the footprint of these dependencies to a minimum, each option type will be defined in its own file (e.g. ExecOptions in actions/types/exec.ts).

[eibens]

While right now the dependencies of each action look very much like other actions, this does not have to always be the case. I think having the actions remain independent of each other is a good choice. Reuse should only happen within a particular layer of the application. The preferred architecture would be:

1. Individual actions that do not depend on other modules, except for static dependencies (e.g. deno/std).
2. A runner interface that wires the actions together and produces event-based output. This is the layer in which dependencies between actions are defined. Here, we redefine the option types (without dependencies) and reuse them for defining the event types.
3. A CLI interface on top of the runner interface. It knows the names of actions in the context of the wiring and derives text-based output from the events.

Considering this architecture, this issue is redundant.