Fix: scheduler: properly set data set flags when scheduling actions

This was a sneaky one. The problem is that set_working_set_defaults() zeroes
the entire pe_working_set_t object, meaning that setting any working set flags
will be pointless if set_working_set_defaults() get called. The commonly used
pe_flag_no_counts and pe_flag_no_compat flags would not show any sign of being
missing aside from a trace log.

Importantly, pcmkschedule_actions() calls unpack_cib(), which calls
set_working_set_defaults() when pe_flag_have_status is not set. To handle this
correctly, pass the flags as an argument to pcmkschedule_actions() and
unpack_cib(), which can set them after setting the defaults.

How this affected various components:

• The fencer avoided the problem by calling cluster_status() before

pcmk__schedule_actions(), which is redundant but sets pe_flag_have_status,
thus avoiding the zeroing. However, it did set certain flags when initially
creating the data set, which was pointless since cib_devices_update() (the only
place that used the data set) called pe_reset_working_set() at the end, which
would wipe the flags.

• The scheduler's init_working_set() set some flags when creating the data set,

but then called pe_rset_working_set() for every subsequent call, thus wiping
those flags (before calling pcmk__schedule_actions()).

• crm_simulate mostly avoided the issue by calling cluster_status() before

calling pcmkschedule_actions(). However its --profile option did not, and
profile_file() calls pe_reset_working_set() after every run of
pcmkschedule_actions(), wiping any flags that were set (as well as any custom
timestamp set using --set-datetime).

• crm_resource --restart/--wait and crm_verify set pe_flag_no_counts and

pe_flag_no_compat to no effect