Revisit extension compatibility paradigm

Recent changes in the CiviCRM release cycle mean we, as extension developers, are likely to be on CiviCRM 4.7.x for a long time to come. This is problematic because our current extension compatibility system takes only the major (4) and minor (7) versions into account.

Generally, changes that do not break backward compatibility are allowed into these point releases, so it's possible that a new hook could be introduced in CiviCRM 4.7.30. If I implement that new hook in my 4.7-compatible extension, users on 4.7.29 and earlier will experience unexpected results.

One interesting idea that came out of discussions related to this topic is that we should consider versioning CiviCRM's API separately from the core, and that extensions could declare compatibility with APIs instead of core. This line of thought is promising but raises a number of questions in itself. What constitutes the CiviCRM API? Certainly there is the REST API that most people think of when we say "API," but there is also a system of hooks, the Civi interface, several core utility classes (e.g., CRM_Utils_Array), and a handful of classes (e.g., those related to SMS) which third party developers are expected to extend. All of these are in circulation in a number of popular extensions, and I'm sure there are other integration points not in this cursory list. How we identify all the supported integration points, and should these be versioned categorically (e.g. REST v 3.x.x, hooks v 4.x.x) or in aggregate (v 4.x.x)?