Add support for Nucleo-L4R5ZI board

[rpls]

This adds support for Nucleo-L4R5ZI board, a fairly large (in terms of 640KB of SRAM) Cortex-M4 based board. This also includes a memory timing test (used to determine the memory timings of the board), and a small fix for the bikel{1,3} source (they checked for STM32F4 definition, which isn't defined for this or any other non STM32F4 board).

Maybe one point that needs discussion is the memory layout of the board. The board has three SRAMs, all in one continuous address space:

• SRAM1: 192KB
• SRAM2: 64KB
• SRAM3: 384KB

The memory timing test showed that the first SRAM1 block has slightly faster load timings. This is a similar situation as with the STM32F4-Discovery board: There, first SRAM block also has faster timings than the second one (maybe a general situation for the Cortex-M4?). Only in that case, the second block isn't much of a loss with 16KB. Here, we can't just ditch any of the blocks without losing a huge chunk of memory. In most cases, this should be fine, as the tests usually put all LUTs in flash or the stack. However, as soon as a LUT or similar object overlaps SRAM1/2, there might be a timing side-channel. Not the end of the world for a benchmarking platform, but still annoying. For now I just use the entire RAM as one large block, mostly to have a physical platform with a lot of memory. Timings should be expected to be slightly slower than the STM32F4-Discovery, as most operations would use the SRAM2/3 (as the stack is there), which exhibits slightly worse timings in for loads.

To flash the board, you'll need at least OpenOCD 0.11. Also included is a custom openocd script, since the board appears to have a different reset procedure than most other Nucleo/Discovery boards. While st-util can flash this board, it will in some cases end up in a weird reset state and hang. The openocd variant works reliably for me.

[mkannwischer]

Sorry for the loooong delay. It all works smoothly for me and is ready to be merged. Thanks @rpls!
Here are the results of one benchmarking run with gcc 10.2.1.

benchmarks.md
benchmarks.csv

I don't really know how we should present results for different platforms without confusing people in the future. I don't think it is feasible to re-run benchmarks on all platforms for each PR, so I don't want to put them into the git repo. Any ideas?