Slow side-channel free AES fallback

In the Go standard library, there are a lot of different optimized implementations for AES. However, the [_fallback_ implementation](https://golang.org/src/crypto/aes/block.go) is still a T-tables based implementation, vulnerable to cache timing attacks. There is a long-standing issue in [golang/go](https://github.com/golang/go) asking to solve this: https://github.com/golang/go/issues/13795

Although these vulnerable implementations should almost _never_ be selected, it seems that they might sometimes be selected. For example, if the AES intrinsics are missing on Intel, the code seems to [select a vulnerable key-expansion](https://golang.org/src/crypto/aes/cipher_asm.go#L97).

The solution to this would likely result in an AES implementation that is *a lot* slower, but I think this is preferable to an implementation that is insecure according to modern crypto engineering standards. In any case, most of the time Go will be able to use an optimized implementation anyway.

## Goal

Provide a side-channel resistant replacement for [`encryptBlock`](https://golang.org/src/crypto/aes/block.go#L44) and [`decryptBlock`](https://golang.org/src/crypto/aes/block.go#L90) and [`expandKeyGo`](https://golang.org/src/crypto/aes/block.go#L148).

## Ideas

To replace [`encryptBlock`](https://golang.org/src/crypto/aes/block.go#L44) and [`decryptBlock`](https://golang.org/src/crypto/aes/block.go#L90), a {16x/24x/32x} bitsliced implementation would be straightforward for AES{128/192/256}. I am thinking, can we maybe do better in the AES128 case? (Parallelizing over multiple blocks is not possible with the current API.)

- [ ] Prioritize readability and simplicity over performance.
- [ ] One function should implement all AES variants.
- [ ] Implementation should be single block-based.
- [ ] [key schedule] Try a scanning-lookup-table approach for `SubWord`?