Potentially refactoring ConnectionStatus

[dilyn-corner]

With the merging of #47, I came across a few things that gave me some pause. I think it's worth considering.

I left some initial thoughts here.

What I can surmise from the reference code and documentation is that there are certain return values that don't actually originate from the board itself, but are rather things the code does. The big example is ConnectionStatus::Idle (WL_STATUS_IDLE). It looks like it's just a value that gets periodically returned while the board is doing something. For instance, the value crops up in a lot of loops, e.g. WiFiClass::begin.

It makes me wonder if we should instead consider that consumers of our crate want these sorts of things exposed, for whatever reason they might want to use them - as it stands, I don't think ConnectionStatus::Idle is ever returned by the board in this context, and our code doesn't return this. I don't know to what extent things like this exist in the rest of the code, so this might just be a supreme-level nit on a single enum, but at the very least it's something worth keeping in mind as we draw closer to 0.3.

[dilyn-corner]

After further discussion with Jim, we instead arrived at the following conclusion:

ConnectionStatus::Idle can be safely removed.

It seems like WL_STATUS_IDLE is merely a sort of placeholder - it's just some way to have a default value to compare to. It's never truly returned in any of the code blocks it appears in. This makes it quite unique.

[jhodapp]

Well summarized Dilyn. We also are leaving open the possibility that ScanCompleted could make sense to move into a separate type since it's not logically related to connection status. This is left as a TODO and will be explored a bit later.