Refactor: libcrmcommon: New pcmk__cluster_option_t:context member

Arguably makes more sense adjacent to the type member, but this
placement keeps the diffs smaller when updating existing options arrays.

We will use this soon to ensure that each option occurs in exactly one
daemon's metadata. Several options (for example,
PCMK_OPT_NO_QUORUM_POLICY) currently appear in the metadata of both the
controller and the scheduler, causing issues for external tools that
parse the output.

Where an option currently appears in the metadata of both the controller
and the scheduler, it will soon appear only in the scheduler's metadata.
We assign context flags accordingly.

Note that the fencer doesn't have a context flag. The options in its
metadata are actually stonith device instance attributes, not cluster
options. They will continue to reside in a separate table from the
cluster options, so there's no ambiguity about which daemon they "belong
to."

Ref T746

Signed-off-by: Reid Wahl <nrwahl@protonmail.com>