Semantic versioning for EC API

[ids1024]

This is something I've been thinking of as a possible issue for various things.

• For charge thresholds in Gnome Control Center, it would probably good to only show the setting for firmware that persists thresholds (Charging thresholds don't persist through an EC reset #128), and otherwise behaves how we want the feature to ultimately work (Default charge thresholds need to match profile #143). How can it check that?
  • Though this one raises the separate issue of how it would make the request to the EC since it doesn't use ectool.
• Similarly, how can the Keyboard Configurator check that the EC is recent enough? We'll want to add more functionality for it to the firmware before release, and the Configurator may not work as expected with the earliest firmware version with support for changing the keymap.
• In general, how could a program like the configurator test if the firmware is new enough to support certain features, to conditionally support them?
• If we add functionality to the API, does it have to stay there forever? If we want/need to make a breaking change, how can that be handled?

I think I possible solution for all of these issues is to have a semver for the API. Then, for instance, the Configurator can refuse to work with EC firmware below a minimum version or a full version too high.

Ideally it would never need a semver bump, but it seems good to have that option. The other obvious solution is to support multiple API versions that the client can choose, like some services do, but that seems like a bad idea in firmware. A client program however could work with multiple EC API semvers.