[RFC] OCF modularity with optional standardized addon profiles

I touched this topic recently [1]:

> [...] an idea of modularizing OCF standard with base + addon
> profiles plus the way how the agents would express which addon
> profile they require somewhere in the metadata.
>
> Hence, existing agents calling out to `attrd_updater` would start
> requiring `node-annotations` (or `node-annotations-1.6` if
> particular minimal version of the standard was required) addon profile,
> would start sourcing `$CRM_PROFILE_LIB/node-annotations.sh` file (in
> case of shell implementation, similar mechanism for other supported
> languages) provided by given cluster resource manager (CRM) and
> containing implementations of functions prescribed in the standard
> (respective addon profile), e.g. `ocfaddon_na_set`.

or `ocfao_na_set` for a shorter prefix

> Of course, CRM groking that the resource requires addon profiles
> it cannot satisfy would declare a failure with the resource right
> away.
>
> [...]
>
> But I have very little insights into how much demand it is there
> for something like this today.

Suggested profiles to legitimize current beyond-standard inverse
dependencies on CRM:

* node-annotations
- agents/resources currently calling out to `attrd_updater`
(per the initial idea above)

* multicluster-tickets
- agents/resources calling out to `crm_ticket` (and perhaps more)

Note that as mentioned, the mentioned delegation to particular
executables would be abstraced per particular CRM, allowing
interoperability with any CRM opting to deliver such addon
functionality and also easier testing (extensions to `ocft`?).

Also current clones and multistate agents could be fully legitimized
when turned into OCF + addon profile(s) requirement on the interface
with CRM. This would require more robust coverage of the use cases,
as, e.g. IPaddr2 can _optionally_ become clone, but it doesn't need
to be run like that.

[1] https://oss.clusterlabs.org/pipermail/users/2018-April/014815.html

Start by reviewing the OCF specification and the proposal's attrd_updater, crm_ticket, and ocft references; no implementation file or test is identified. Done would require an agreed scope for addon profiles, CRM capability negotiation, and coverage of clone and multistate use cases, followed by an explicit validation plan.

Written by the indexing model from the issue text.