Read a bloom filter for the columns a query filters on (#314)

[ChronicallyJD]

Closes #314. Follows #315, and the two compound.

A predicate probes one column, so a group that is examined needs the filters of
the columns carrying predicates and no others. The reader fetched the whole
group's filters and used at most one per predicate, so a single equality
predicate on a twelve column table read twelve bloom bitmaps and probed one.

Why it is worth removing

A bloom filter holds one bitmap per column sized by the group's distinct values,
which makes it among the larger things in the metadata catalog.

bloom_pkey is (storage_id, group_number, column_index), so naming the column
makes the fetch an exact index lookup rather than a range scan whose unwanted
rows the caller discards. All three key columns are equality, so this is a probe,
not a narrowed range.

Measured

One group of 200,000 rows, twelve int columns, scanned whole with one equality
predicate:

	buffers
before	715
after	323
bloom read deleted outright	251

The 251 is a floor and not a target: the probed column's filter has to be read.

Compounding with #315, on the 20-group probe from that PR:

	buffers
before #315	9577
after #315	1946
after this	1547

Per-skipped-group cost is unchanged at about 64, as expected. #315 already
removed the bloom read for skipped groups; this is about the groups that are
kept.

Test

test/bloom_lazy.sh gains four checks, taking it to 20.

The property: six columns' filters cost more to read than one column's. With the
whole-group read those two queries were identical, because the work did not
depend on the query at all. Measured 20 blocks against 120. Block reads are
counted against pgcolumnar.bloom with pg_stat_get_blocks_fetched, so what is
asserted is the thing that changed.

A correction to the suite this PR builds on

The existing #310 control, "a scan that keeps every group reads more", was
passing for the wrong reason. It used a column whose values are unique across the
table, so its zone map excluded every group but one: it claimed to vary the group
count and actually varied the column count. It went red under the #310 removal
proof, which is why it looked sound.

One column now repeats every 1000 rows, so a single equality predicate keeps
every group, and a new check asserts that the control query really does keep them
all before the property that depends on it is tested.

Worth stating plainly, because it is a limit of the removal-proof discipline
rather than a slip: a removal proof shows a check can go red, not that it goes
red for the stated reason. A fixture that is silently degenerate still responds
to the guard being removed, by a path nobody intended. Fixtures with a
precondition should assert the precondition as its own check.

Proved by removal, both ways

restored	result
the all-column read	1 and 6 predicates both cost 21 blocks; the two #314 checks red
the eager whole-group read	all four checks red

The two guards fire independently, so the suite covers both properties rather
than one standing in for the other.

Gates

Five-major matrix (15, 16, 17, 18.4, 19beta2).

[ChronicallyJD]

Subsumed by #313, same as #314/#315 were. #313 already reads the bloom both lazily (only for groups the zone map didn't exclude) and per column (ColumnarReadBloom(storageId, group, pred->attidx), only the probed column) — which is exactly what #314/#317 ask for. It has the interleaved 43× A/B, full PG18+PG19 matrix, and ASan clean.

Closing as superseded by #313.

@jdatcmd heads-up: #313, #315, and #317 are the same fix arriving from multiple concurrent sessions of mine. Please review #313 — it's the complete, validated one; the others are subsets. I'm going to stop opening/closing duplicates in this area.