Remove unnecessary rt-crate dependencies

[bjoernQ]

• we can just remove the rt-crates from the PACs since they are not used there (anymore?)
• binary crates only need them to use the entry-macro but we can re-export it from the chip specific HALs - as a bonus that way there is no need to differentiate between the two architectures
• when we re-export from esp-hal-common we also don't need the dependency in the chip-specific HALs

So, in the end only esp-hal-common would depend on the rt-crates which makes maintenance much easier.
For users it also eliminates a source of frustration since having more than one version of an rt-crate in the dependency tree will cause ugly linker errors (plus they don't even need to know that there is an rt-crate involved at all)

[jessebraham]

we can just remove the rt-crates from the PACs since they are not used there (anymore?)

Fine with me, easy enough to remove them. The dependency is only in there because the svd2rust documentation says to add it, but it's not actually required so we can drop it along with the rt feature.

binary crates only need them to use the entry-macro but we can re-export it from the chip specific HALs - as a bonus that way there is no need to differentiate between the two architectures

I don't have an issue with this specifically, but given that we've just changed this and are now changing it again, maybe it's worth having a bit more discussion about? I just don't want the location of the entry macro to keep changing over and over, you know?

when we re-export from esp-hal-common we also don't need the dependency in the chip-specific HALs

This is definitely a nice perk!

For users it also eliminates a source of frustration since having more than one version of an rt-crate in the dependency tree will cause ugly linker errors (plus they don't even need to know that there is an rt-crate involved at all)

This is also a very good point. Overall I'd say let's move forward with this, again let's just make sure things we've covered all angles.

[bjoernQ]

Fine with me, easy enough to remove them. The dependency is only in there because the svd2rust documentation says to add it, but it's not actually required so we can drop it along with the rt feature.

I think we need to keep the rt feature just because it's used in the generated code - I think they don't include the interrupt vectors without rt but not a big deal - getting rid of the rt-crates would be great

I don't have an issue with this specifically, but given that we've just changed this and are now changing it again, maybe it's worth having a bit more discussion about? I just don't want the location of the entry macro to keep changing over and over, you know?

The good thing here is, that we haven't published the version using esp-riscv-rt so officially we only change this once - and when we do it, we never ever really need to change it since we are in control

Overall I'd say let's move forward with this, again let's just make sure things we've covered all angles.

I don't see any downside of all this - but well it's my proposal so maybe I'm a bit biased. I think it will make everyone's life easier

[MabezDev]

Fewer places to have to bump PRs is a good thing! I currently don't see any downside to this, so I think we should do it.