fix(data): profiles: clean up after multiple inheritance

[ThinkOpenly]

Za64rs ("Reservation sets are a maximum of 64 bytes.") conflicts with Za128rs ("Reservation sets must be at most 128 bytes in size.").

Most profiles don't automatically incorporate optional extensions from "ancestors", so more extensions need to be removed after profile inheritance.

For example, in UDB, profile RVA23S64 inherits from both RVB23S64 and RVA23U64. However, in the profiles documentation it (roughly) inherits from only RVA23U64, and then only "all the mandatory unprivileged extensions". So, the optional extensions need to be handled more explicitly, and many need to be removed.

Fixes #1195

[jordancarlin]

Za64rs ("Reservation sets are a maximum of 64 bytes.") conflicts with Za128rs ("Reservation sets must be at most 128 bytes in size.").

I'd argue Za64rs implies Za128rs instead of conflicting with it. A max reservation set size of 64 bytes inherently means it meets a max size of 128 bytes.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 46.05%. Comparing base (7d94f86) to head (8b9b8f6).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1230   +/-   ##
=======================================
  Coverage   46.05%   46.05%           
=======================================
  Files          11       11           
  Lines        4942     4942           
  Branches     1345     1345           
=======================================
  Hits         2276     2276           
  Misses       2666     2666           

Flag	Coverage Δ
idlc	46.05% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ThinkOpenly]

Za64rs ("Reservation sets are a maximum of 64 bytes.") conflicts with Za128rs ("Reservation sets must be at most 128 bytes in size.").

I'd argue Za64rs implies Za128rs instead of conflicting with it. A max reservation set size of 64 bytes inherently means it meets a max size of 128 bytes.

Technically, yes, I suppose. It kinda depends on how you look at it. It's misleading to claim support for reservations sets up to 128 bytes when you really only support up to 64 bytes. I'm not sure how claiming support for Za128rs is helpful when the actual maximum is 64 bytes? What could you do with that extra information?