Add run-operation to click CLI (#5552)

[jtcohen6]

resolves #5552

Sorry, just couldn't let others have all the fun...

L'engagement

• Add RunOperationTask to click CLI
• Add macro positional argument

Le tour

Borrowing 63870d5 locally, to avoid the error Object of type SpawnContext is not JSON serializable:

$ python3 -m pytest tests/functional/run_operations/
==================================== test session starts ====================================
platform darwin -- Python 3.10.9, pytest-7.2.0, pluggy-1.0.0
rootdir: /Users/jerco/dev/product/dbt-core, configfile: pytest.ini
plugins: csv-3.0.0, logbook-1.2.0, xdist-3.1.0, flaky-3.7.0, mock-3.10.0, dotenv-0.5.2, cov-4.0.0
collected 10 items

tests/functional/run_operations/test_run_operations.py ..........                     [100%]

==================================== 10 passed in 8.47s =====================================

🎩 Le prestige

{% macro say_hello(whomst="world", strong=False) %}
    {{ print("Hello " ~ whomst ~ (" !" if strong else "")) }}
{% endmacro %}

$ python3 -m dbt.cli.main run-operation say_hello
Hello world
$ python3 -m dbt.cli.main run-operation project_funway.say_hello
Hello world
$ python3 -m dbt.cli.main run-operation say_hello --args 'whomst: Jeremy'
Hello Jeremy
$ python3 -m dbt.cli.main run-operation say_hello --args '{"whomst": "Wisconsin", "strong": true}'
Hello Wisconsin !

Checklist

• I have read the contributing guide and understand what's expected of me
• I have signed the CLA
• I have run this code in development and it appears to resolve the stated issue
• This PR includes tests, or tests are not required/relevant for this PR
• I have opened an issue to add/update docs, or docs changes are not required/relevant for this PR
• I have run changie new to create a changelog entry

[MichelleArk]

tiny nit: could we move this down under @click.pass_context so that all the params are logically grouped together?

[MichelleArk]

also - we should probably define this in core/dbt/cli/params.py alongside the other params for consistency / reuse.

edit, upon a bit more thinking:
A downside to that is that it wont be apparent from the command definition which parameters are arguments vs options. Also, I could see an argument for defining commands and arguments together given arguments can't provide their own help text and are documented by the command.

Alls to say - I think defining the argument here is actually fine, especially given that macros is only used in one command at this point.

[jtcohen6]

Agree with first nit! I'll make the order match the CLI order

For the second - two reasons I prefer keeping it alongside the command definitions:

1. Click arguments can't have documentation / help text, click's recommendation is to document them by mentioning them explicitly in the command help text
2. We have very very few positional arguments in dbt commands. (I think it's just run-operation MACRO and init PROJECT_NAME. I just remembered the latter, and will add in this PR so we don't forget.) These are truly one-offs. IMO adding them as (reusable) params risks the misperception that they're widely used, versus keeping them alongside the only commands for which they're relevant.

[MichelleArk]

just a small nit otherwise LGTM! thank you for picking this up!