Handle overrides in element group derivation

[scootermon]

I have an SVD file with two instances of a peripheral. The second peripheral contains the same registers, but instead of 128 it only has 64. The SVD file uses derivedFrom in the second peripheral to inherit these registers but overrides the <dim> element. To my surprise, svd2rust generated arrays with the same number of elements for both instances.
Well, after following the trail I ended up here and the reason wasn't hard to find.

I saw #283 and the follow up #286, but there's little to no reasoning attached to these PRs.

Looking at the spec here I really don't see a reason why the fields from dimElementGroup shouldn't also be overridden.
The derivedFrom description reads

Specify the register name from which to inherit data. Elements specified subsequently override inherited values.

I can't see a statement about the dimElementGroup elements somehow being exempt.

[adamgreig]

Thanks for the PR and sorry for the delay in reviewing! LGTM but I don't understand why the CI workflows haven't run and there doesn't seem to be the usual option to approve running them. Maybe if you run another force push it will run/allow approving to run?

Otherwise all seems OK so we could merge through the merge queue which will run CI too. @burrbull / @Emilgardis ?

[burrbull]

Unfortunately the spec does not fully describe behavior during derive. I not sure about correctness of code neither before PR not after (I afraid that partial derive of dim group could cause tag conflicts). I need see real example what was working wrong and how it should work.