Implement a means to ignore selected compatibility errors

[michaelbromley]

Is your feature request related to a problem? Please describe.
We have a mechanism by which Vendure plugins can specify compatibility by using the compatibility property of the plugin metadata object.

If a range is specified, this is checked at bootstrap time and if any plugin is incompatible with the version of Vendure core being used, an exception will be thrown and the server will not start.

However, there will be cases where this behaviour is problematic. For instance, if using a 3rd-party plugin that has not been updated to include compatibility for a newer version, even though that newer version does not contain any breaking changes that would impair the functionality of the plugin.

In this case, the ideal solution is that the plugin author promptly issues a new version with an updated compatibility range. In reality, this may not happen in a timely manner.

Describe the solution you'd like
There should be an explicit way to opt-out of the exception for specific, named plugins. This would be an escape hatch to handle these rare cases where you know for sure that the plugin will still work safely.

It would look something like this:

{
  ignoreCompatibilityErrors: [PluginA, PluginB]
}

Where should this setting go? There are 2 options:

1. Somewhere in VendureConfig. Most likely in the systemOptions object.
2. In the BootstrapOptions passed to the bootstrap() function.

Describe alternatives you've considered
An alternative would be to allow you to do this:

{
  compatibilityErrorSeverity: 'error' | 'warning'
}

where setting it to 'warning' would still display the message but would not stop bootstrap.

I tend to prefer the version where you have to explicitly name every plugin you want to ignore. That way there's no chance that you just lazily set it to "warning" and then run into actual issues due to real compatibility problems.

[michaelbromley]

I decided to make this option part of the bootstrap options, rather than the VendureConfig. The reason for this is that it is a dangerous option and I don't want it to be possible to manipulate the value from inside a plugin. It should be explicitly set at the top-level by the app owner.