turn `setting` into a cannon action

[dbeal-eth]

current implementation of settings has a few significant problems that make it difficult:

• settings cannot depend on other settings, which makes it hard to have derivative computed values
• settings cannot derive from other steps, such as the result of a recent contract deployment. again, wuold be nice for overrides

the optimal solution for this is to have settings be included as a regular step type. this makes sense too, because we have specific exclusions for settings throughout the code.

a setting step, when executed, would basically just add its setting result to the build outputs. the builder would maintain a list of "defined values" for CLI options which are included, but these are not checked against anything. they are more like environment variables.