Add ParquetMetadata::memory_size size estimation

[alamb]

Draft as I need to implement memory size calculations for the schema structs as well

Which issue does this PR close?

Closes #1729

Rationale for this change

For systems that want to do low latency queries on parquet files stored in
object store, it is important to somehow provide the ParquetMetadata to the reader to
avoid the overhead of fetching the file footer and re-parsing the metadata.

For example, when using the ArrowReaderMetadata API:

arrow-rs/parquet/src/arrow/arrow_reader/mod.rs

Lines 293 to 315 in ed018a3

	/// The metadata necessary to construct a [`ArrowReaderBuilder`]
	///
	/// Note this structure is cheaply clone-able as it consists of several arcs.
	///
	/// This structure allows
	///
	/// 1. Loading metadata for a file once and then using that same metadata to
	/// construct multiple separate readers, for example, to distribute readers
	/// across multiple threads
	///
	/// 2. Using a cached copy of the [`ParquetMetadata`] rather than reading it
	/// from the file each time a reader is constructed.
	///
	/// [`ParquetMetadata`]: crate::file::metadata::ParquetMetaData
	#[derive(Debug, Clone)]
	pub struct ArrowReaderMetadata {
	/// The Parquet Metadata, if known aprior
	pub(crate) metadata: Arc<ParquetMetaData>,
	/// The Arrow Schema
	pub(crate) schema: SchemaRef,
	pub(crate) fields: Option<Arc<ParquetField>>,
	}

One way to provide ParquetMetadata to the Arrow reader is to cache it in memory and for large numbers
of parquet files this can consume non trivial memory. Thus accurately understanding the memory requirements
is important

What changes are included in this PR?

1. Add ParquetMetadata::memory_size(), named similarly to arrow::Array::get_array_memory_size
2. Add a non public trait to help calculate memory usage
3. Tests

Are there any user-facing changes?

There is a new function in the API

[alamb]

I chose to add as many memory estimation calculations as possible in their own module rather than sprinkling it next to the structure definitions. I put it next to the structures when the internal fields are private.

I can put the code next to the definitions if people think that would be cleaner / less likely to be forgotten if new fields are added in the future

[alamb]

Here is the (only) new API introduced in this PR

[alamb]

this shows there is non trivial overhead with storing these structures -- 2K already for a 2 column with a single row group

[alamb]

I plan to merge this in later today as well unless there are any additional comments or people would like additional time to review