Refactor of granularity in tables.

[alanmcruickshank]

#81 migrated several OR statements into a consistent artifact_run_id. This was a good improvement but results in a few tricky issues about granularity.

Situation:

• dbt cloud job, which runs seed, run and test (I don't believe the problem I'm highlighting would occur in the case of running build).
• After each step we run upload_artifacts macros.
• The created artifacts would have run_results for each step, with each of the models/tests/seeds executed at each step (which is good) and also a duplicate manifest for each, with a different command_invocation_id but the same artifact_run_id.
• The current proposed MERGE statements in Switch to merges in the upload scripts #99 don't solve this situation currently because we're merging on artifact_run_id AND atrifact_generated_at.
• This means that when we start joining on artifact_run_id in models we get a cartesian join and more rows than we need. Most specifically in stg_dbt__node_executions, but also in fct_dbt__snapshot_executions, fct_dbt__seed_executions & fct_dbt__model_executions.

I think the solution to this is to change the join in these cases to join only on command_invocation_id which is unique to a given artifact - and avoids the cartesian join.