Polymorphic subtype deduction based on 'presence' of fields does not take 'absence' of fields into account

**Describe the bug**
Our use case involves the following:
We are calling a web service that returns a JSON response that is a composite object. The object has a member field which is itself an object whos field members change depending on the service called, therefore we implemented this object as an interface with a number of different implementations corresponding to each different service, so it is a "polymorphic" member of the response object. Therefore, we placed the `@JsonTypeInfo(use = DEDUCTION)` annotation a top this interface definition.

In one particular service call, this response object returns with an empty object for this polymorphic member. When this case occurs, an error similar to the following is encountered(say we have only two implementations defined in the `@JsonSubTypes` annotation) :
```
com.fasterxml.jackson.databind.exc.InvalidTypeIdException: Cannot deduce unique subtype of `com.engageft.jackson.deserialization.issue.objects.AnInterface` (2 candidates match)
at [Source: (String)"{
"compositeClassIntMember":11235,
"compositeClassStringMember":"compositeClassString",
"polyMorphicMember":{

}
}"; line: 6, column: 4] (through reference chain: com.engageft.jackson.deserialization.issue.objects.CompositeClass["polyMorphicMember"])
at com.fasterxml.jackson.databind.jsontype.impl.AsDeductionTypeDeserializer.deserializeTypedFromObject(AsDeductionTypeDeserializer.java:131)
```
We then thought we'd try creating an implementation of this polymorphic member without any fields specifically for this case of an empty response object in the hopes that this mechanism would find this "empty implementation" and use it, but this did not work.

After examining the code found [here](https://github.com/FasterXML/jackson-databind/commit/9a271ef422fc060f9fcb3c4aac2d99860963a8ff), it appears that the case, or situation of if/when a particular implementation contains _no_ data members is not being accounted for.

Other than this, we find this functionality absolutely fantastic and immensely helpful! Thank you for adding it! We hope that you might find a way to account for and solve this issue.
I realize this is probably an outlier of a use case, and so is probably one that is very easily overlooked.

If you think you may benefit from any further assistance from me on this matter please do not hesitate to let me know :) .

**Version information**
Which Jackson version(s) was this for?
jackson-databind-2.12.0

**To Reproduce**
I've created a small project which demonstrates this issue and it's located [here](https://github.com/lderienzo/jackson-polymorphic-deserialization-issue).

**Expected behavior**
The tests in the test project should outline the whole thing, but if they don't please let me know.

**Additional context**
Can't think of any at the moment, but if I do, I'll amend this.