Feature: state:modified.macros

[jtcohen6]

resolves #2704
resolves #3278
resolves this tweet

Description

If a macro's SQL is modified, mark any node that depends on it (or depends on a macro that depends on it) as modified.

While I was here, it was trivial to make sub-selectors (finally) happen:

• state:modified.body
• state:modified.configs
• state:modified.persisted_descriptions
• state:modified.database_representations state:modified.relation
• state:modified.macros

For review

• I don't really know how to write recursive functions :)
• Let's revisit some of the nomenclature here (vs. the original proposal in Subselectors for state:modified #2704). Even though it's a mouthful, I prefer persisted_descriptions vs. just descriptions, to be clear it's the subset with persist_docs enabled. On the other hand, I'm not sure about modified.database_representations vs. something shorter & sweeter like modified.relations.
• There are a few more same_x checks (same_fqn, same_quoting, same_external) that are resource-specific and wouldn't have dedicated subselectors in this first round. I think that's ok—these aren't ones we've heard as much demand for, and they're still included in the state:modified superset—just worth calling out.

Checklist

• 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 updated the CHANGELOG.md and added information about my change to the "dbt next" section.

[jtcohen6]

Thanks for the reviews @nathaniel-may @kwigley! I added some comments where the code wasn't clear.

I ended up renaming state:modified.database_representations to state:modified.relation. I think I like it better that way. Relation is a wonkier word, but it's one that dbt users should be familiar with as indicating database.schema.table.

I spent slightly too long thinking about which of these sub-selector names should be singular and which should be plural. I decided to use "per node" as the frame, such that:

• one body per node
• multiple configs per node
• multiple persisted_descriptions per node (potentially relation + columns)
• one relation per node
• multiple macros that a node may depend on