Handle C-modules that are extended by a frozen module (ESP32 - machine.py)

Some modules are built of a combination of : - C - Frozen python files. Stubber does not handle this well, not at all in fact. The first encounter is: - https://github.com/micropython/micropython/blob/master/ports/esp32/modules/machine.py - introduced in : https://github.com/micropython/micropython/commit/327655905e9f523070301f2f35459197d46db4fb This was unexpected - and breaks the stub merge/collation by overwriting machine.pyi with a partial implementation ## breakdown - manifest contains partial/complementary machine.py module - this is saved as a frozen module that should be included - it is then turned into a stub ( mypy stubgen ) - that stub is then enriched with the reference stub classes and type info - which ironically made it harder to detect ( stubber enrich ) - during the final build proces the partial `frozen.machine.pyi` overwrote the intended `machine.pyi` ## Current workaround : skip copying machine.pyi from the frozen stubs altogether STUBS_COPY_FILTER = { StubSource.FROZEN: [ "machine", # esp32.frozen.machine.py is used to implement PCNT # https://github.com/micropython/micropython/blob/master/ports/esp32/modules/machine.py ] ## Future - is this a common pattern with more internal + frozen modules ? - limit the enhancement of the fozen.machine.py - append the additional methods & classes - add documentation for these classes - add the classes to the reference ? - add @mp_availability(port="esp32")