sas: Fix the base64 encoding of the MAC.

Please note that this is a breaking change, so we'll likely need to introduce another calculate_mac() method instead of applying this patch as is.

When calculating the MAC for a message using olm_sas_calculate_mac() and olm_sas_calculate_mac_long_kdf() the resulting MAC will be base64 encoded using _olm_encode_base64().

The _olm_encode_base64() method requires an input buffer and output buffer to be passed alongside the input length. The method is called with the same buffer, containing the MAC, for the input buffer as well as for the output buffer. This results in an incorrectly base64 encoded MAC.

For example the byte array:

[121, 105, 187, 19, 37, 94, 119, 248, 224, 34, 94, 29, 157, 5,
 15, 230, 246, 115, 236, 217, 80, 78, 56, 200, 80, 200, 82, 158,
 168, 179, 10, 230]

will be encoded as

eWm7NyVeVmXgbVhnYlZobllsWm9ibGxzV205aWJHeHo

instead of as

eWm7EyVed/jgIl4dnQUP5vZz7NlQTjjIUMhSnqizCuY

Notice the different value at the 10th character.

The correct result can be independently checked using Python for example:

>>> from base64 import b64encode
>>> mac = [121, 105, 187, 19, 37, 94, 119, 248, 224, 34, 94, 29, 157, \
           5, 15, 230, 246, 115, 236, 217, 80, 78, 56, 200, 80, 200, \
           82, 158, 168, 179, 10, 230]
>>> b64encode(bytearray(mac)).rstrip(b"=")
>>> b'eWm7EyVed/jgIl4dnQUP5vZz7NlQTjjIUMhSnqizCuY'

This happens because the _olm_encode_base64() method that is used does not support in-place encoding in the general case. This is because the remainder for a 32 bit input will always be 2 (32 % 6 == 2).

The remainder will be used over here: https://gitlab.matrix.org/matrix-org/olm/-/blob/c01164f001d57fbe2297fe11954b58077a68dc0d/src/base64.cpp#L74

The logic that gets executed if a remainder exists depends on the original input values, since those already got in-place encoded, the whole block will behave differently if the input buffer is the same as the output buffer.