Refactor logic analyzer

[bessman]

This is the first part of the major refactorization I'm currently working on. It refactors the logic analyzer instrument, as well as the underlying hardware drivers it depends on, including:

• Input Capture (IC)
• Direct Memory Access (DMA)
• Input Change Notification (CN)
• Timers (TMR)

This pull request breaks any instrument which depend on an interrupt service routine from any of the above drivers. This is because I'm refactoring the interrupts to be more modular by using callbacks. The broken instruments will be fixed as part of the ongoing refactorization.

The new low-level hardware drivers currently reside in src/registers_ng, to be renamed to src/registers once the refactorization is complete. These drivers are designed to be self-contained, i.e. they have no dependencies on any resources other than themselves. This design aims to solve the current spaghetti-ness of the firmware code, where every module depends on several other modules, often in a transitive or circular manner.

Depends on #165 and #166.

[CloudyPadmal]

I was thinking about having a separate development branch. That way, we have a protected master or main branch and once development is tested, we can merge the two. What do you think?

[bessman]

In general, I don't think it's necessary for small projects with few committers to have parallel main and development branches. I prefer to have all development go into main, while tagging periodic releases.

On the other hand, merging known broken code (which this is) into main is nasty. So in this case, it makes sense to keep this work in a separate branch until the refactorization is complete.

[bessman]

Going to merge this soon (into the new and probably temporary 'develop' branch).

Some notes on this change:

• Some functionality has been removed from the logic analyzer, specifically:
  • The ability to cascade and prescale timers. This feature is useful to look at signals with long time periods between edges. I see this as a niche use case, but the feature could be re-added in the future.
  • The ability to capture such events as 'every fours rising edge' and 'every sixteenth rising edge' and the like. I don't see a use case for this. Available capture events are now 'any edge', 'falling edge', and 'rising edge'.
  • The ability to configure multiple pins as trigger source simultaneously. I don't see a use case for this. At most one pin at a time can now be configured as trigger source.
• A lot of now-obsolete code hasn't yet been removed. It will be removed at a later stage of the refactorization (in a separate pull request).