This is a follow-up PR to GH-24402.

Currently, *base64.b64decode* uses a generic regex to validate *s* (when *validate* is true),
which sometimes results in unexpected behavior and exception messages.

Example:

(1)    base64.b64decode('ab==',  validate=True) # b'i'
(2)    base64.b64decode('ab3==', validate=True) # b'i\xbd'
(3)    base64.b64decode('ab=3=', validate=True) # raises binascii.Error: Non-base64 digit found
(4)    base64.b64decode('ab==3', validate=True) # raises binascii.Error: Non-base64 digit found
(5)    base64.b64decode('ab===', validate=True) # raises binascii.Error: Non-base64 digit found
(6)    base64.b64decode('=ab==', validate=True) # raises binascii.Error: Non-base64 digit found

The only strict-base64 valid example here is (1).
(2), (4) and (5) should raise 'Excess data after padding',
(3) should raise 'Discontinuous padding not allowed',
and (6) should raise 'Leading padding not allowed'.

To get this behavior, we can use the new (at the time of creating this PR) *binascii.a2b_base64* functionality of strict mode.

I have one (not so big) concern - efficiency.
I'm not that experienced with how fast regex-es are (in Python or in general) compared to the implementation of *binascii.a2b_base64* in C.
So, I've no idea what would be the impact of migrating from regex pre-validation to input parsing.
Let me know if you find it inefficient.

-----

Referenced issue (GH-24402): https://bugs.python.org/issue43086