Allow "optional-padding" for `Base64Variant`

(note: follow-up from https://github.com/FasterXML/jackson-databind/issues/2183)

Currently Base64Variant instances either require use of specific padding character (and use it for output) or disable use of padding completely (neither written nor accepted). But it seems that sometimes a more lenient variant would make sense: one that

1. Does write padding (with specific character) and
2. Accepts specific padding but does not require it (i.e. ok to omit)

It seems best to add a “mutant factory” method in Base64Variant instance (something like withLenientPadding(boolean) maybe?). Whether additional entries should be added Base64Variants is an open question. We’ll have to figure out what to do wrt existing “usePadding()” compared to new option; API may be cumbersome if we have 2 booleans but just 3 legal combinations.

Note that we may also change API for configuration for Jackson 3.x, later on.

[cowtowncoder]

I would think chaining would usually be used like

Base64Variant base64Variant = Base64Variants.MIME.withPaddingForbidden();

I specifically do not want to make Base64Variants mutable as they are immutable as that just opens up many new ways to get things to fail in interesting ways. 😃

[cowtowncoder]

@pavan-kalyan Addition of new constructors would be needed yes, and expected. Existing constructors should be left for compatibility reasons, although may be deprecated if that makes sense (for eventual removal from 3.0).

I do not remember exact details of current set up but I think it is rigidly keeping settings so that if padding is used on writing, it must be found on reading too.