This commit extends the test runner to automatically discover inline
assembler tests for known RV32 extensions, and checks whether to add the
discovered tests to the enabled tests list.

Automatic discovery requires that inline assembler tests for RV32
extensions follow a specific pattern both for filenames and for the
tests' output in case of success.  A valid RV32 extension test must
have:

  * A code fragment that checks for support of the extension on the
    running target in "/tests/feature_check", called
    "inlineasm_rv32_<extensionname>.py" that should print the string
    "rv32_<extensionname>" if the extension is supported
  * A matching expected result file in "/tests/feature_check" called
    "inlineasm_rv32_<extensionname>.py.exp" that must contain the string
    "rv32_<extensionname>" (without quotes)
  * A regular MicroPython test file in "/tests/inlineasm/rv32" called
    "asm_ext_<extensionname>.py"

For example, to test the Zba extension, there must be a file called
"/tests/feature_check/inlineasm_rv32_zba.py" that should print the
string "rv32_zba" if the extension is supported, together with a file
called "/test/feature_check/inlineasm_rv32_zba.py.exp" that contains the
string "rv32_zba" in it, and finally there must be a regular MicroPython
test file called "/tests/inlineasm/rv32/asm_ext_zba.py".

Signed-off-by: Alessandro Gatti <[email protected]>

This commit performs the necessary changes to handle an additional RV32
CPU extension flag, for the Zcmp extension in this case.

The changes are not limited to RV32-only code, as other parts of the
tooling need to be modified for this: the testing framework has to be
made aware that an extra bit can be set in sys.implementation._mpy and
needs to know how it is called, and "mpy-cross" must be able to actually
set that flag bit in the first place via the appropriate command line
argument.

Signed-off-by: Alessandro Gatti <[email protected]>

This commit introduces the possibility of using Zcmp opcodes when
generating function prologues and epilogues, reducing the generated code
size.

With the addition of selected Zcmp opcodes, each generated function can
be up to 30 bytes shorter and having a faster prologue and epilogue.  If
Zcmp opcodes can be used then register saving is a matter of a simple
CM.PUSH opcode rather than a series of C.SWSP opcodes.  Conversely,
register restoring is a single CM.POPRET opcode instead of a series of
C.LWSP opcodes followed by a C.JR RA opcode.  This should also lead to
faster code given that there's only one opcode doing the registers
saving rather than a series of them.

For functions that allocate less than three locals then the generated
code will allocate up to 12 bytes of unused stack space.  Whilst this is
a relatively rare occurrence for generated native and viper code,
inline assembler blocks will probably incur into this penalty.  Still,
considering that at the moment the only targets that support Zcmp
opcodes are relatively high-end MCUs (the RP2350 in RV32 mode and the
ESP32P4), this is probably not much of an issue.

Signed-off-by: Alessandro Gatti <[email protected]>