attachInterrupt implementation remarks

In this repo, some additions to `attachInterrupt` have been made to allow passing an extra argument. See https://github.com/arduino/ArduinoCore-API/blob/master/api/Interrupts.h#L19-L34

I have a few remarks/questions about his:
- I do not really like the use of a container in dynamic memory here and wonder if that is really needed. On second reading, I see that passing a *pointer* to `attachInterrupt` already skips the wrapper lambda and dynamic memory, it is just other types that need it. Technically, the wrapper lambda and container only serve to convert a pointer to a reference argument, which I suspect is actually a no-op on most architectures (but that's probably hard to guarantee...).
- The implementation currently seems to not free the container on detachInterrupt, which leads to memory leaks. I can't quickly think of an easy way to fix this either, without modifying the underlying interrupt handler table to somehow mark these interrupts as dynamic.
- The argument is passed by reference and then a pointer to it is taken and stored in the container. I'm wondering if this API is understood well enough, or if people would end up passing local variables resulting in all kinds of breakage. Possibly people expect to be able to pass the argument by value, so perhaps that would be a better way to implement this? As an optimization, values that are exactly as big as a pointer could be passed without the wrapper and container, but that must assume things about the architecture-specific calling conventions, so might not be acceptable here.
- ~~AFAICS the API repo provides `attachInterrupt()` and the underlying core provides `attachInterruptParam`. However, the `attachInterrupt()` method now accepts a parameter, so the naming distinction is weird. I guess the distinction is really between the sketch-visible `attachInterrupt()` API and the internal API-to-core `attachInterruptParam()` API. So perhaps the latter should be renamed to `attachInterruptInternal()` or something similar? There might be other APIs where something like this also happens that could benefit from a clear naming convention as well.~~ Update: Seems that only a C++ overload for `attachInterrupt` *with* param is implemented, so a core needs to implement both with and without param versions. Also, `attachInterruptParam()` should probably be user-visible, to allow using it from within C code.
- AFAICS there is no `attachInterrupt()` without the extra parameter defined here, so I assume the core is expected to define that directly? For consistency, it might be better to have *all* sketch-visible versions defined here, and define only "Internal" versions in the core (where `attachInterrupt()` without the extra param defined here will then simply call the equivalent internal version without adding anything). Alternatively, the core could define *only* a param version which is then used without the non-param version, but that either requires an extra wrapper lambda (passing the original function in the extra param) resulting in extra runtime delay, or passing a param to a function that does not accept it (which is probably acceptable on register-based architectures, but cannot be guaranteed everywhere. There has been some discussion about this in https://github.com/arduino/ArduinoCore-avr/pull/58 and https://github.com/arduino/Arduino/pull/4519). So perhaps the current approach (letting the core define both a param and param-less version) is actually the best, since then the core can decide to handle both in the same way if acceptable on that architecture, or store the validity of the argument separately if needed).

Commencez par les lignes 19-34 de api/Interrupts.h et comparez les surcharges de attachInterrupt visibles depuis le sketch avec l’implémentation de attachInterruptParam destinée au core. Examinez les discussions ArduinoCore-avr et Arduino liées pour prendre connaissance des contraintes existantes ; la tâche n’est terminée qu’une fois qu’une approche a été définie pour la propriété, la durée de vie des arguments et le nommage dans le comportement de attach et detach.

Rédigé par le modèle d'indexation à partir du texte de l'issue.