Warning severity configuration

[emereum]

This PR adds a new warningSeverity configuration option. This option allows consumers to promote specific warnings to exceptions. This solves the issue where some consumers have unique needs for error reporting, such as #3618, while still respecting MobX's error reporting strategy in the default case.

Example usage:

configure({
    warningSeverity: {
        computedRequiresReaction: "throw",
        enforceActionsStrict: "throw",
        enforceActionsNonStrict: "throw",
        observableRequiresReaction: "throw",
        derivationWithoutDependencies: "throw"
    }
})

Warnings will default to warn which is in line with their current behaviour in 6.8.0.

[changeset-bot]

🦋 Changeset detected

Latest commit: cdc6ede

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
mobx	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[emereum]

Hey @iChenLei do you think there is a scenario where this change could be introduced? On one hand, it solves #3618, on the other I see how it might make triaging user bug reports more difficult - folks might promote warnings to errors, then submit bug reports here that aren't applicable to a default warning configuration.

In this case, we could suffix exceptions with something like: "You are seeing this error because you have configured MobX to throw when this occurs. Please revert your warning severity configuration and retry before reporting issues to MobX"

[emereum]

@urugator keen to get your thoughts on this PR as well as my comments above on the potential downsides and ways to mitigate them.