[CT-2352] Versioned Models - parsing and referencing

[MichelleArk]

Introduce an optional ‘versions’ attribute on model yaml entry. versions is a list of 'version' structures. Spec:

models:
  - name: dim_customers
    latest_version: 2
    config:
      materialized: table
    columns:
      - name: customer_id
        description: This is the primary key
        data_type: int

    versions: # new!
      - v: 2
        # implemented_by: dim_customers_v2 - optional, this is the default naming convention
      - v: 1
        defined_in: dim_customers_any_filename
        config:
          alias: dim_customers
        columns:
          - include: * 
            exclude: customer_id
          - name: customer_id
            data_type: float 

Acceptance Criteria

• each version of a model is its own node in the manifest - with its unique id model.{project_name}.{model_name}.v{version}
• all versions of a model have the same value for their name attribute
• each version of this model is "defined in" a model SQL/python file. The defined_in property points to the name of a .sql (or .py) file that implements that model version. By convention, this file is <model_name>_v.sql, e.g. dim_customers_v2.sql. However, users could set defined_in to point to a different SQL file that doesn't meet the default naming convention. (These file names must be globally unique, even though they are not the actual model name.)
• the alias of a versioned model is not based on its file name. Instead, it is either the alias from the versioned config (if available) or defaults to {model_name}_v{version} if not.
• the v key for versions accepts a string - and orders versions within a model by attempting to cast to an int or float, and falling back on string / alphanumeric ordering
• ref supports a new keyword argument - version (or v alias) - that retrieves the specified version of a model. if version is not provided to ref for a versioned model, ref retrieves the latest version of the model.
• versioned models inherit any properties / configurations from the 'base' model. Additionally, they may have at most one IncludeExclude object in their columns list to avoid re-specifying most columns from the 'root' model.