Release 3.0.0

[ia0]

Required tasks:

• Use static dispatch instead of dynamic dispatch
• Use static instead of const for pre-defined encodings
• Make Encoding implementation private
• Add _uninit() version to support MaybeUninit outputs
• Move development work in lib/v3
• Make encode_len() return a Result such that {en,de}code_len() return an error (could be a new ErrorKind::Overflow) in case the following arithmetic would overflow by computing the bound and documenting it (see Document length limits for which functions are guaranteed to produce the correct result #145)
• Introduce explicit traits to avoid users seeing True and False (also useful to avoid parameter ordering issues)
• Restrict symbols to printable/graphical ASCII?
• Do we really need wrapping separator of up to 255 bytes? Seems like 15 would be enough.
• Add a third option for padding: NoPad, PadConcat, PadFinal (new). [context]
• Add a fourth option for padding: PadLoose(encode: bool) similar to PadFinal but padding may be absent (see Support ECMA262's proposal-arraybuffer-base64 #152) and encode describes whether encoding adds padding or not
• Do not panic for recoverable errors, return an error instead (see avoid panic in decode_mut #126) actually we should be no-panic on no-alloc
• It should be possible to define custom encodings with const fn
• Figure out MSRV (in particular if 1.84 would solve the problem definitely)
• Update documentation once satisfied with the design
• Update OSS-Fuzz to also fuzz lib/v3

Optional tasks:

• Consider whether wrapping should be limited to multiple of the decoding block (use case)
• Consider accepting a shorter output and only decoding until it's filled (use case)
• Make decoding output-driven instead of input-driven which should solve the point above
• Consider decode_len looking at the last bytes of the input to give a tighter (and exact without ignored characters) bound
• Identify and fix performance regression with "wrap" functions
• Add SIMD support (see SIMD optimization #95)
• Consider whether a "short input" engine for base58, nix-base32, z85, etc would be worth it (see Support Nix base32 #110)

After release:

• Update OSS-Fuzz if needed