Useless start-charge commands

[MikeBishop]

Related to #575 and saving our limited quota of commands.

Some of the cases where we treat a failed attempt to start charging as a non-failure, we could detect from the car data we're already querying and not issue the command in the first place. For example:

• It's typical for a car to refuse to charge because it's complete, especially when we attempt to restart it after it finishes its charge. Given that we're already querying the charge and charge limit, can we skip sending a charge command to cars where the charge level is >= the limit? Can we set stopAsking when a car was actively charging and stops spontaneously around the time we expected it to?
• It's typical for a car to refuse to charge because it's not connected to a charging station. Given that the charge state exposes a Disconnected state, can we skip sending a charge command to cars that report they're not plugged in?

[ngardiner]

Great points. There are likely times when we fetch details and rather than parsing all of the values in the response we look for the one thing we care about at that point in time and throw the rest away.

This would be a good opportunity to build states into our vehicle class and populate them from values we extract from the API, and use those states to reduce further API activity when it would be unnecessary based on a given state.

[MikeBishop]

Some of that was improved as a side-effect with the move to vehicle data. When we make a call to vehicle data, we do store everything we care about and then return the one we were looking for at the moment. We also don't make calls for vehicle data if we've just made one recently. I think the main thing we need in this vein is to identify local state we could examine to avoid a command call.