Merged PR 2629: Integrates logic to detect New Dashboard users within DWH

# Description

First step towards reporting New Dash is to be able within DWH to know which hosts have been migrated.
In order to do so, and anticipating that there's going to be new phases in the future, I've created a `int_core__user_migration` model that reads from a configuration macro `get_new_dash_migration_phases_config` that will allow semi-automatic user retrieval in the future. This avoids nasty hardcoding within the model itself.
The information of whether a user is migrated, in which phase and when the phase was deployed is available at user level in the `int_core__user_host` table.

# Checklist

- [X] The edited models and dependants run properly with production data.
- [X] The edited models are sufficiently documented.
- [X] The edited models contain PK tests, and I've ran and passed them.
- [X] I have checked for DRY opportunities with other models and docs.
- [X] I've picked the right materialization for the affected models. **-> I selected a view for this model since I don't believe we should materialse this data other than the user host table**

# Other

- [ ] Check if a full-refresh is required after this PR is merged.

Related work items: #19570

macros/user_migration_configuration.sql

@@ -0,0 +1,32 @@
+/*
+Macro: get_new_dash_migration_phases_configuration
+
+Provides a general configuration for the different phases of the
+    New Dash migration. Each phase is identifiable via a phase_name,
+    that is the "expected display" for users. The assumption is that
+    each user migration is identified via claim_type. Lastly, we 
+    apply here a hardcode of when the deployment was carried out.
+
+Important note: if a user migrates once a phase has started, we 
+    will not be able to tell when that happened. However, it is likely
+    that other indicators will provide an estimate. For example:
+
+    The migration A happens on 1st July 2024. 
+    User A is migrated on 1st July 2024 (as expected)
+    User B is migrated on 10th July 2024 (not expected)
+
+    It is likely that User B won't have Bookings from new dash
+    until it's migrated. So this migration date should be considered
+    as a hard, lower-limit of dates.
+*/
+
+{% macro get_new_dash_migration_phases_config() %}
+    {% set migration_phases = [
+        {
+            'phase_name': 'MVP',
+            'claim_type': 'KYGMVP',
+            'deployment_date': '2024-07-30'
+        }
+    ] %}
+    {{ return(migration_phases) }}
+{% endmacro %}