Fix: executor,scheduler: treat "no secrets" fence results as a hard error

Previously, the executor mapped the fencer's PCMK_EXEC_NO_SECRETS status to
PCMK_EXEC_ERROR to keep handling of that situation the same as before the new
code was added.

However, the earlier handling was less than ideal -- a resource action that
failed due to missing secrets would be retried on the same node, and almost
certainly fail again for the same reason. Now, the executor passes along
PCMK_EXEC_NO_SECRETS to clients; the controller will record the result in the
CIB status, and the scheduler will treat it as a hard error (i.e. not retrying
on the same node).

Backward compatibility isn't a problem because the scheduler treats unknown
status codes the same as PCMK_EXEC_ERROR, so an older DC will continue to
handle it as before. The CRM feature set has been bumped so the handling can't
flip back and forth in a mixed-version cluster.