Replace pg_atomic_flag with pg_atomic_bool

Hi,

I've always found the pg_atomic_flag functions counterintuitive. I
remember by now pretty well how the pg_atomic_u32/u64 functions work,
but any time I have to look at the pg_atomic_flag functions, I feel
not-like I'm in a foreign land.

I think that's because I think of pg_atomic_flag as an atomic version of
"bool". I'd assume there to be functions similar to the u32/u64
functions, like pg_atomic_read_bool() and pg_atomic_write_bool(). But
alas, neither of those functions exist. To read the value, you have to
use pg_atomic_unlocked_test_flag(), and remember that when the flag is
set, it returns *false*, which feels completely backwards to me. It
makes more sense with pg_atomic_test_set_flag(), which returns 'false'
if the flag was already set and hence was not set again, but it
nevertheless just feels wrong to me.

I propose that we replace pg_atomic_flag with pg_atomic_bool, which
behaves more like pg_atomic_u32/u64.

We currently only use pg_atomic_bool in two places: in the shared memory
structs of pg_stash_advise and autovacuum. I actually considered just
removing pg_test_flag altogether and replacing those two uses directly
with pg_atomic_u32, but it's still nice to have a distinct boolean type.
It's worth noting that the current usage is not very performance
critical (not that I'd expect the u32 functions to be any slower).

Thomas's patches to switch to standard C <stdatomic.h> at [1] is also
touching this. They keep the the application-facing functions unchanged,
but changes the implementation to use the same atomic-exchange
instructions as for u32/u64. This is complementary and an independent
topic to discuss, although the patches will conflict.

[1]
https://www.postgresql.org/message-id/CA%2BhUKGKFvu3zyvv3aaj5hHs9VtWcjFAmisOwOc7aOZNc5AF3NA%40mail.gmail.com

- Heikki