How to bypass MrBean for types with existing deserialization logic

This is more of a question, possibly with a suggested change for greater compatibility.

I'm trying to better understand MrBean's [incompatibility with polymorphic types](https://github.com/FasterXML/jackson-modules-base/tree/master/mrbean#issue-incompatibility-with-polymorphic-types), since I'd really like to use both MrBean and ``@JsonTypeInfo``.

From my limited testing, it appears that I can override the ``_suitableType`` method (not sure if that's officially supported), so that I can bypass MrBean's materialization for specific abstract types. When I do this with a polymorphic interface annotated by ``@JsonTypeInfo``, everything seems to work -- Jackson's polymorphic type resolution kicks in, and MrBean can still be used to materialize the specific subclasses/interfaces as desired.

Since I've got that working, I'm exploring how to implement the ``_suitableType`` method generically, and I've found that the following override seems to do the job:
```java
@Override
protected boolean _suitableType(JavaType type) {
return !type.hasHandlers() && super._suitableType(type);
}
```

As far as I can tell from my limited testing (and review of Jackson's code in this area), ``JavaType.hasHandlers`` will return true if the type has a dedicated TypeDeserializer or other deserializer instance. This seems to always be the case for classes that are annotated with ``@JsonTypeInfo``, as well as any other cases where a specific deserializer has been registered.

So, my question is:

1. Is there some downside/pitfall to this generic implementation that I'm missing?
2. If not, could this implementation be added as an enhancement to MrBean itself?

I should note that I'm interested exclusively in the deserialization use case, so perhaps I'm overlooking some complexities in the serialization use case.