Review public API prior to next release

[jessebraham]

The goal is to minimize API surface while still being as useful as possible when using espflash as a library for various use cases.

Related to #794

[MabezDev]

This command gives you just the library docs: cargo doc --no-default-features --features serialport --open

[MabezDev]

I spent a bit of time looking into this, here are some notes from me:

• We likely want to cfg some error cases away that are dependent on the serialport feature We already do this
• We have a Target trait, with no public implementors, seems to me we should ditch the trait and just implement these directly on the Chip enum (and use the chip enum in more places, instead of the struct Esp32 stuff), especially given this sort of impl in the trait: Remove chip target files #891
• Same as above but for the Efuse trait Remove chip target files #891
• Image format module is dependent on changes in Refactor image formatting, and allow supporting new image formats in a backward compatible way #745 so ignoring for now Refactor image format #877
• A tonne of stuff not respecting the Rust API guidelines, but covered by Apply relevant Rust API Guidelines to _library_ sections of espflash #864
• Seems like we have some valuable input here: Investigate espflash library usage #794 (comment). Let's take this into account, particularly about making sure Flasher can be constructed, and reset() via library calls is possible.

Overall, it's not looking to bad, I think most of this could be refactored in a few days. I think we should resolve #745 before tackling these.

I'll also note now, that I don't think we need this to be perfect, we can release another major version of this tool without too much churn later, so to me this is about resolving #745, cleaning up the API as much as we can within a reasonable time constraint then cutting the release.

[MabezDev]

Other notes from my comment in #793:

• Regardless of above, I think Connection should be constructed outside of Flasher to avoid passing in Connection's constructor params into Flasher::connect Move construction of Connection outside of flasher #882
• I don't know where SpiAttachParams should live, it acts like an input but we only ever use SpiAttachParams::default() or SpiAttachParams::esp32_pico_d4(). If we don't plan on allowing the users to configure this, we should try and associate it with Chip, it should simplify a lot of things.
• For cases where there are a large number of input params, that we can't untangle, we should consider a config struct to encapsulate it together.

[MabezDev]

I consider my analysis, and then implementation of changes to be done here. The remaining points (not crossed through), I consider to be nitpicks.

I think the remaining effort should be spent ensuring we enable the use cases for users in #794