Implement new API for reading eFuse values

[jessebraham]

This turned out to be pretty large, so apologies for that. Plenty of the code can be disregarded in review though (i.e. the generated eFuse constants).

This PR introduces a new xtask package to the workspace. While I've been resisting adding this for some time, it's now become a bit of a necessity. This is used to generate the eFuse field definitions from the YAML files defined in the esptool repository.

Additionally, all code relating to reading of eFuse values has been completely rewritten. There are a few hacky bits here and there, mostly relating to the ESP32, but overall I think things are in much better shape. Perhaps we can iterate on this further and improve those areas, however for the time being I'm not too worried about it.

I have tested on all supported devices to confirm that things are working as expected; as far as I can tell, we're in good shape. There is one caveat, on the ESP32-S2 for whatever reason we are not reading the correct BLOCK2 version number; this does not really make sense to me, and honestly I'm getting kind of tired of thinking about eFuses at this point, so happy to just open an issue for this and worry about it later.

Closes #827

[jessebraham]

@SergioGasquez pointed out that there may be a few more opportunities to use the field constants rather than read_efuse_raw for the ESP32, so will look into that shortly.

EDIT: This is done.

[MabezDev]

This is looking great, way more grok-able than the random bit shifts :D.

I have a couple of initial comments to address. I'm also aware that we also have some efuse field generation in esp-hal's xtask, is the plan to retire that and keep field generation here and periodically copy the (presumably the .rs) files over to esp-hal?

[jessebraham]

I'm also aware that we also have some efuse field generation in esp-hal's xtask, is the plan to retire that and keep field generation here and periodically copy the (presumably the .rs) files over to esp-hal?

I don't know what the plan is, meant to bring this up in the original comment. Probably it's not a bad idea to even have a separate esp-efuse package or something, but as we were discussing yesterday I'm hesitant to keep creating packages until we have improved our release workflow.

Open to suggestions here, was just going with the path of least resistance to get something working.

[jessebraham]

Probably I should update the CI workflow to ensure the xtask package builds, too. Forgot about that.

[SergioGasquez]

LGTM! Thanks for working on this, it's definitely way better now!

[jessebraham]

I'm also aware that we also have some efuse field generation in esp-hal's xtask, is the plan to retire that and keep field generation here and periodically copy the (presumably the .rs) files over to esp-hal?

I don't know what the plan is, meant to bring this up in the original comment. Probably it's not a bad idea to even have a separate esp-efuse package or something, but as we were discussing yesterday I'm hesitant to keep creating packages until we have improved our release workflow.

Open to suggestions here, was just going with the path of least resistance to get something working.

Regarding this, probably our options are:

1. Keep the eFuse field generation code in one repo only, either here or in esp-hal, and just copy-paste the files between repositories as needed
2. Create a new esp-efuse package which includes this functionality and provides the field definitions for all target devices
3. Duplicate the code between repositories and not worry about it too much

Probably 1 or 2 are the preferable choices, don't really care much which we go with. I also think this can be decided on at a later date and does not need to block this PR.

I think I have completed everything I planned to here for the time being, so unless there are additional review comments to address then it should be okay to merge whenever.

[SergioGasquez]

1. Keep the eFuse field generation code in one repo only, either here or in esp-hal, and just copy-paste the files between repositories as needed
2. Create a new esp-efuse package which includes this functionality and provides the field definitions for all target devices
3. Duplicate the code between repositories and not worry about it too much

I would also lean towards 1 or 2, maybe I like having a standalone package a bit more, it shouldn't be too difficult to maintain and release.

[MabezDev]

1 or 2 seems best here, probably 1 initially and we can push it into it's own crate after.