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