feat!: use Uint8Array in alphabet() and radix

[ChALkeR]

Caution

This limits radix methods to 8-bit max
This is a breaking change

No high-level methods depend on that though (i.e. no base512 etc)

This also switches bech to uint8 words instead of array

It does only a ~5-30% performance improvement, mostly due to this still operating on arrays in join
I decided to file this first though to make changes more atomic

Unifying join, padding, and alphabet into a single method would solve this

Before:

base32 (encode) 32 B scure x 715,819 ops/sec @ 1μs/op ± 1.30% (1μs..5ms)
base32 (decode) 32 B scure x 1,273,885 ops/sec @ 785ns/op ± 2.69% (583ns..7ms)
base32 (encode) 64 B scure x 408,663 ops/sec @ 2μs/op
base32 (decode) 64 B scure x 753,012 ops/sec @ 1μs/op ± 1.09% (1μs..1ms)
base32 (encode) 1 KB scure x 26,949 ops/sec @ 37μs/op ± 1.72% (35μs..8ms)
base32 (decode) 1 KB scure x 50,607 ops/sec @ 19μs/op
base32 (encode) 8 KB scure x 3,285 ops/sec @ 304μs/op
base32 (decode) 8 KB scure x 5,789 ops/sec @ 172μs/op
base32 (encode) 1 MB scure x 13 ops/sec @ 74ms/op ± 2.81% (69ms..80ms)
base32 (decode) 1 MB scure x 25 ops/sec @ 39ms/op ± 3.51% (36ms..50ms)

After:

base32 (encode) 32 B scure x 931,966 ops/sec @ 1μs/op ± 2.55% (833ns..10ms)
base32 (decode) 32 B scure x 1,353,179 ops/sec @ 739ns/op ± 3.12% (541ns..6ms)
base32 (encode) 64 B scure x 546,746 ops/sec @ 1μs/op ± 1.20% (1μs..1ms)
base32 (decode) 64 B scure x 790,513 ops/sec @ 1μs/op ± 2.31% (1μs..5ms)
base32 (encode) 1 KB scure x 36,623 ops/sec @ 27μs/op ± 1.96% (24μs..9ms)
base32 (decode) 1 KB scure x 68,170 ops/sec @ 14μs/op
base32 (encode) 8 KB scure x 4,852 ops/sec @ 206μs/op
base32 (decode) 8 KB scure x 8,857 ops/sec @ 112μs/op
base32 (encode) 1 MB scure x 25 ops/sec @ 39ms/op ± 2.70% (36ms..47ms)
base32 (decode) 1 MB scure x 62 ops/sec @ 15ms/op

[paulmillr]

seems like 2-2.5x boost on 1mb

[ChALkeR]

this was a mistake, it threw because i was not defined