Reclassify user related errors

[WilliamDee]

Context

We throw a bunch of different exceptions for different scenarios. In attempts to categorize the errors appropriately, we will introduce a InformativeError which denotes that it isn't a system error from MF, but an error that falls under the bucket of things that a user can tweak in their input (either in their manifest config or query formulation) or it's just not supported.

This isn't a complete solution, but there will be further efforts to classify more and make all the error handling be more verbose.

[plypaul]

LGTM, but please see comments. Also, I was thinking of adding a base exception class like:

https://github.com/dbt-labs/metricflow/blob/p/semantic_graph.pr_1760_comment/metricflow-semantics/metricflow_semantics/experimental/metricflow_exception.py

[plypaul]

What errors aren't informational?

[WilliamDee]

There's probably a better naming for this, but just trying to categorize it into the buckets of system/internal errors vs user/featurenotsupported/configerror/etc... and the latter I considered as informational to the user

[WilliamDee]

Updated to InformativeUserError if that's any better and updated the docstring

[WilliamDee]

LGTM, but please see comments. Also, I was thinking of adding a base exception class like:

https://github.com/dbt-labs/metricflow/blob/p/semantic_graph.pr_1760_comment/metricflow-semantics/metricflow_semantics/experimental/metricflow_exception.py

@plypaul yea the InformationalUserError can inherit the base MetricflowException. I was just thinking we should be able to have a catch-all exception that allows us to know this is an error that is not actionable on our end (not a bug or anything)

[plypaul]

To clarify, I haven't thought much about the exception class hierarchy, and the linked file was for reference, not that we need to put that in right now.