Made DatePart an ExtendedEnum (#207)

### Description

Made DatePart an ExtendedEnum so that users don't have to worry about
case when entering values into `date_part()`. Copy-pasted MF comment so
that we can remove DatePart from MF.

### Checklist

- [x] I have read [the contributing
guide](https://github.com/dbt-labs/dbt-semantic-interfaces/blob/main/CONTRIBUTING.md)
and understand what's expected of me
- [x] I have signed the
[CLA](https://docs.getdbt.com/docs/contributor-license-agreements)
- [x] This PR includes tests, or tests are not required/relevant for
this PR
- [x] I have run `changie new` to [create a changelog
entry](https://github.com/dbt-labs/dbt-semantic-interfaces/blob/main/CONTRIBUTING.md#adding-a-changelog-entry)

.changes/unreleased/Under the Hood-20231107-175844.yaml

@@ -0,0 +1,6 @@
+kind: Under the Hood
+body: made DatePart an ExtendedEnum
+time: 2023-11-07T17:58:44.412914-06:00
+custom:
+  Author: DevonFulcher
+  Issue: None

dbt_semantic_interfaces/type_enums/date_part.py

@@ -1,14 +1,28 @@
-from enum import Enum
 from typing import List
 
-from dbt_semantic_interfaces.enum_extension import assert_values_exhausted
+from dbt_semantic_interfaces.enum_extension import ExtendedEnum, assert_values_exhausted
 from dbt_semantic_interfaces.type_enums.time_granularity import TimeGranularity
 
 
-class DatePart(Enum):
+class DatePart(ExtendedEnum):
     """Date parts able to be extracted from a time dimension.
 
-    Week is not an option due to divergent results across engine contexts see: https://github.com/dbt-labs/metricflow/pull/812
+    Note this does not support WEEK (aka WEEKOFYEAR), because week numbering is very strange.
+    The ISO spec calls for weeks to start on Monday. Fair enough. It also calls for years to
+    start on Monday, but only about 1 out of every 7 do. In order to ensure years start on
+    Monday, the ISO decided that the first day of any given year is the Monday of the week
+    containing the first Thursday of that year. Consequently, the ISO standard produces
+    weeks numbered 1-53, but any days belonging to the preceding calendar year but in the
+    first week of the new year are part of the new ISO year. This is not really what people
+    expect.
+
+    But there's more - different SQL engines also have different implementations of week of year.
+    When not using ISO, you get either 0-53, 1-54, or 1-53 with different ways of deciding
+    how to count the first few days in any given year. As such, we just don't support this.
+
+    When the time comes, we can support week using whatever standard makes the most sense for
+    our usage context, but as it is not clear what that standard looks like we simply don't
+    support date_part = week for now.
 
     TODO: add support for hour, minute, second once those granularities are available
     """