FluidFramework: Stop using ErrorType enums in base error interface/type definitions

[edit: per conversation below, the outcome here may be in the opposite direction from the original statement. Stay tuned]

In https://github.com/microsoft/FluidFramework/pull/8803 I realized that since we constrain the type of errorType in our error interface/type definitions, any change to the enum breaks backwards or forwards compatibility, potentially in a lot of places.

As far as I see it, the purpose of this constraint is to help devs creating errors to use the right set of errorType values in a given context, and not for a consumer of these error interfaces/types. All these errors end up being cast to IErrorBase in the end, which has errorType: string. Anywhere that uses a variable of a specialized type (with specialized errorType) would be just as well-served to use IErrorBase instead.

To avoid the pain for consumers of our packages represented by breaking changes, I’m proposing we switch to using errorType: string. We will have to be more deliberate in PRs to encourage proper/constrained values for errorType, but I think the precedence of using enum values and not string literals throughout the code is enough.