[Model WatchTower] Add ArtifactConfig (+OSS-2427) & model version management in context (partially)

[avishniakov]

Describe changes

I implemented ArtifactConfig and overrides for Model Objects and Deployments to be used by users in Annotated objects of steps outputs.

To support this feature I also extended pipeline and step runners to:

• Once steps enter context we create a new ModelVersion, if it was requested. It will be called zenml.constants. RUNNING_MODEL_VERSION. (see `zenml.orchestrators/step_runner.py::_prepare_model_context_for_step)
• Once step is completed we link artifacts with valid annotation to a version, which was prepared (if needed) on enter
• Once the pipeline is succeeded we register_running_versions giving them a valid version number (integer increments), so running will become 24, if 23 was the previous greatest.

I also extended a bit structure of ArtifactLinks to support versioned links using the same name (also auto-incremented integer).

Example of attachments:

@step
def a()->Tuple[Annotated[int,"1"],Annotated[int,"2",ArtifactConfig(model_name="artifact")]]:
    link_output_to_model(ArtifactConfig(model_name="manual"), output_name="1")
    return 1,2

@step
def b():
    link_output_to_model(ArtifactConfig(model_name="manual")
    return 1

@step
def c()->Annotated[int,"10"]:
    return 10

@step(enable_cache=False, model_config=ModelConfig(name="step"))
def d()->Annotated[int,"100"]:
    return 100

@pipeline(enable_cache=False, model_config=ModelConfig(name="pipe"))
def p():
    a()
    b()
    c()
    d()

if __name__=="__main__":
    p()

In the example above output artifacts will be linked to ModelVersions as follows:

• "2" will get Model from artifact config => artifact
• "1" is manually linked with link_output_to_model => manual
• Output of b() is not named, but is linked manually => manual
• "10" get implicit linking from pipeline => pipe
• "100" get implicit linking from step => step

So Resolution Order is: ArtifactConfig/Manual>@step>@pipeline

Pre-requisites

Please ensure you have done the following:

• I have read the CONTRIBUTING.md document.
• If my change requires a change to docs, I have updated the documentation accordingly.
• If I have added an integration, I have updated the integrations table and the corresponding website section.
• I have added tests to cover my changes.
• I have based my new branch on develop and the open PR is targeting develop. If your branch wasn't based on develop read Contribution guide on rebasing branch to develop.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Other (add details above)

[avishniakov]

@fa9r , CI passed well for me - there were some failures, but not related to this (addressed in Discord). Can you recheck my comments and approve/reject those?

[fa9r]

LGTM let's get this merged 🙌

[fa9r]

Generally I'd suggest looking into this again to figure out whether there's a cleaner solution to the circular import, but since it's the only open issue on this PR I'd also be fine with just merging it