arm: Use AP specific types & enumerate Addresses rather than APs

[ithinuel]

• Enumerate Memory AP addresses instead of giving the number of valid
  (Generic and Memory) APs.
  This will enable future development where APv2’s live in disjoint memory
  spaces.
• Use AP specific types
  This should allow future developments to enabled things like secure
  debug, memory tagging, etc
• Drop ApInformation and MemoryApInformation
  The AP specific types carry these information internally so these types
  are no longer required.

Follows:

• arm: Use FullyQualifiedApAddresses rather than GenericAp or MemoryAp #2706

[github-actions]

The following changelog fragments do not match the expected pattern:

• changelog/draft.md

Files should start with one of the categories followed by a dash, and end with '.md'
For example: 'added-foo-bar.md'

Valid categories are:

• added
• changed
• fixed
• removed

[ithinuel]

@bugadani I’m sorry the last commit is bigger, I didn’t really now how to detangle the various parts.

[ithinuel]

There are a few things that I’m not fully satisfied in this PR but I had to stop somewhere :P
Just to list a few:

• The methods remaining in ArmMemoryInterface.
  • The way we have to return Result<&mut _, _> etc. Something feels off about it.
  • The newly introduced base_address.
• The mocks that seem to implement the same trait in slightly different ways (based on the tests needs).
  This adds lots of noise and require changes anytime there’s an unrelated change in the trait.
  It’d be easier with 1 well features mock for the other tests to use.

There are more refactor coming with the introduction of APv2 & ADIv6 (mostly moving some modules around to make place for an "apv2" module.

[bugadani]

NGL this is very hard to review. I don't have experience with the code, and even though I assume most of this is just pushing stuff around, I can't track what goes where. The size of the whole diff makes my computer cry, and the online vscode is just not optimal to read diffs either :)

Because we squash PRs into single commits, I would recommend to split out the independent parts into separate PRs. That would make them easier to review and approve, as well as change tracking/blaming/reverting independent parts becomes about an order of magnitude easier.

I would recommend submitting the initial refactors in one go, the bugfix in a second phase, and the last commit's madness last. As you said the last commit is hard to split up, I guess I'll have to bite the bullet there, but it will take time and it would be unfortunate if the PR gathered conflicts in the meantime - merging the rest should somewhat reduce the diff surface to help with that.

[ithinuel]

I openned the following PRs:

• add test-log to dev-deps #2700
• Fix private documentation #2701
• arm: use docsplay::Display for ArmError #2702
• arm: Fix ApType variant names & fix corresponding documentation #2703
• arm: Rename ArmProbe to ArmMemoryInterface #2704
• Factorize memory interfaces implementations #2705
• arm: Use FullyQualifiedApAddresses rather than GenericAp or MemoryAp #2706
• arm: Move ArmMemoryInterface up one module level #2708

and converted this one back to draft, hopefully I can clarify this madness.

[bugadani]

I'm not done reviewing yet, completing this will take time.

[bugadani]

@Tiwalun should I leave this PR unmerged for a short while, or you'll only have comments after 5 minutes after it gets merged? 🫠

[Tiwalun]

I think my interpretation of a short while is different than yours 😄

Feel free to merge this, I don't think I have time to look at this before the weekend.