range_deserialize + range_get_flags

I noticed a weird thing about rangetypes API while reviewing multiranges
-- the combination of range_deserialize immediately followed by
range_get_flags.  It seems quite odd to have range_deserialize return
only one flag (empty) and force callers to use a separate
range_get_flags call in order to fetch anything else they need.  I
propose that it's simpler to have range_deserialize have an out param
for flags (replacing "empty"), and callers can examine "IsEmpty" from
that using a macro accessor.  So there are two macros now:
RangeFlagsIsEmpty() takes the 'flags' value and return whether the bit
is set.  Its companion RangeIsEmpty() does the range_get_flags() dance.

The attached patch does that, with a net savings of 8 lines of code in
rangetypes.c.  I know, it's not amazing.  But it's slightly cleaner this
way IMO.

The reason things are this way is that initially (commit 4429f6a9e3e1)
were all opaque; the external observer could only see "empty" when
deserializing the value.  Then commit 37ee4b75db8f added
range_get_flags() to obtain the flags from a range, but at that point it
was only used in places that did not deserialized the range anyway, so
it was okay.  I think it was commit c66e4f138b04 that ended up having
both deserialize and get_flags in succession.  So things are weird now,
but they have not always been like that.


I also chose to represent the flags out param as uint8 in
range_deserialize.  With this change, the compiler warns for callers
using the old API (it used to take bool *), giving a chance to update.

-- 
Álvaro Herrera