Define Hipcheck API evolution plan

[alilleybrinker]

Hipcheck is currently at major version 3, and thus is subject to (or at least ought to follow, to be a good open source ecosystem participant) Semantic Versioning, and avoid breaking users. At the same time, the goals for Hipcheck in 2024 involve improvements and changes to the API which will almost certainly involve deprecation of existing APIs and transition to new ones.

To achieve this, we need to define a process and associated code for handling deprecation, transition, and eventual removal of existing APIs which will no longer be supported.

The goal is for the existing APIs and the new APIs to coexist for a period, and then to have a cut-off major version break where deprecated APIs are removed. Any removal should also involve a transition plan from the old APIs to the new ones, to be documented in the Hipcheck documentation.

An RFD should be drafted which specifies Hipcheck's evolution plan, including how we will handle identifying deprecated APIs to the user, how we can guide the user to documentation for transition, and planning for eventual removal.

This is separate from identification of specific APIs which will be deprecated; it is focused solely on defining the deprecation process.