Reintroduce: Write Bloom filters between row groups instead of the end

[alamb]

This re-installs the changes from #5860 from @progval which I accidentally merged even though it has API changes. I reverted in #5932 and now this PR has the changes queued up again

[adriangb]

While working on #6000 I excluded bloom filters because they're not part of file::ParquetMetadata. Conceptually, are bloom filters part of the metadata or something else? Should they be added to ParquetMetadata? In particular wrt to #6002 if we're going to be creating APIs for encoding/decoding metadata more directly it would be good to understand what constitutes metadata and what doesn't. If bloom filters are part of metadata I do think it'll be important to have the right APIs to avoid loading them if unwanted since they can get quite large compared to other metadata.

[alamb]

Per discussion on #6050 I am going to merge this branch to the 53.0.0-dev feature branch, where we are collecting PRs with breaking changes before master opens

[alamb]

While working on #6000 I excluded bloom filters because they're not part of file::ParquetMetadata. Conceptually, are bloom filters part of the metadata or something else? Should they be added to ParquetMetadata? In particular wrt to #6002 if we're going to be creating APIs for encoding/decoding metadata more directly it would be good to understand what constitutes metadata and what doesn't. If bloom filters are part of metadata I do think it'll be important to have the right APIs to avoid loading them if unwanted since they can get quite large compared to other metadata.

@adriangb -- I am not sure if bloom filters are conceptually part of the metadata.

Similarly to ColumnIndex and OffsetIndex, the BloomFilter is stored "out of line" with the metadata in the file footer

So TLDR is I think it would be reasonable to add BloomFilters to ParquetMetadata, especially once we have a better API or encoding/decoding it.

[alamb]

Merging to feature branch