Remove `JsonSerializer.isEmpty()` from 3.0

[Shenker93]

Actually it is not an issue, but improvement request.
Now Base.isEmpty from JsonSerializable takes SerializerProvider as parameter.After some research I found out, that this class is extended by lots of other classes in jackson-databind and most of them use default implementation from Base (it returns false). Only ArrayNode & ObjectNode override isEmpty, but SerializerProvider is not used at all.
Using isEmpty method, you have three generic ways how to deal with it in client code:

1. Pass the SerializerProvider object. So, we need to create an object that will not be used and just'll be collected during the next GC run. Also, the code becomes more complicated and tightly coupled in general, polluted by unnecessary dependencies and object creations, you need to choose proper SerializerProvider implementation(especially if you have custom ones),etc.
2. Pass null. No errors, no unnecessary object creation/cleanup, but this approach can lead to error-prone situations in future(if this parameter will be used in some way in future releases) and looks weird as for current release.
3. Use size() == 0, if provided, as alternative. More verbose and less effective approach depending on inner collections. (i.e. ObjectNode uses Map under the hood and delegates size computing to implementation from map object).

The proposal is to remove this unused parameter from method signature in 3.0 or other major release if there are no counter arguments. Overloading is the option too(and even can be added in minor release), it saves backward compatibility (and brings new uncertainty, which method to use, too :-) )

[cowtowncoder]

Ok, just to make sure: parameterless version is indeed removed from 3.0. Version that takes SerializerProvider has to be used, and caller must not pass null there. It is only to be called from places that do have access to this context object.
The reason for passing is to give access to:

1. Active configuration, mostly via contained SerializationConfig, and
2. Access to contextual attributes (for custom serializers)
3. Access to underlying JsonGenerator (rare, advanced use cases)

So even if existing serializers do not make much use of it, pretty much all active handlers on serialization should either take SerializerProvider (counterpart for deser being DeserializationContext), or SerializationConfig.

[cowtowncoder]

Note: removal done earlier, as part of removing all 2.x deprecated methods (with minor exceptions for cases still unresolved, number in single digits).