Fix: fencing: Broadcast uname as soon as a peer's state has changed

The behavior was mistakenly changed by commit df1825e. Given the
condition (type == crm_status_uname), we would never know peers'
unames unless we initiated a fencing, started a STONITH_OP_QUERY and
received uname broadcasts from peers. However, according to the logic
related to uname in fencing_peer_active(), we didn't actually calculate
the correct number of expected replies before we started the
STONITH_OP_QUERY. Hence, we would ignore the later but valuable replies,
and could mistakenly think no one could fence the target node, which would
introduce fencing failure.

This commit reverts the condition of sending uname broadcasts back to
(type != crm_status_processes). So nodes will broadcast unames as early
as possible, once a peer's state has changed.