[Variant] Simplify creation of Variants from metadata and value

[alamb]

Which issue does this PR close?

• Part of [EPIC] [Parquet] Implement Variant type support in Parquet #6736

Rationale for this change

While making documentation / examples for working with Variant in #7661, I found it was somewhat awkward to make Variant values directly from the metadata and value. Specifically you have to

let metadata = [0x01, 0x00, 0x00];
let value = [0x09, 0x48, 0x49];
// parse the header metadata
let metadata = VariantMetadata::try_new(&metadata).unwrap();
// and only then can you make the Variant
Variant::try_new(&metadata, &value).unwrap()

I would really like to be able to create Variant directly from metadata and value without having to make a VariantMetadata structure

What changes are included in this PR?

This PR proposes a small change to the API so creating a Variant now looks like:

let metadata = [0x01, 0x00, 0x00];
let value = [0x09, 0x48, 0x49];
// You can now make the Variant directly from the metadata and value
Variant::try_new(&metadata, &value).unwrap()

Are there any user-facing changes?

Yes, the API for creating APIs is slightly different (and I think better)

[alamb]

This is the core difference -- rather than having a reference to a VariantMetadata Objects and Arrays now have the objects inlined (and the objects themselves have references to the underlying &[u8])

Note that VariantMetadata is a pointer and a few usize so I think it is better to inline them anyways rather than have an extra layer of indirection

[scovich]

One fat pointer, two usize, and a VariantMetadataHeader that should easily pack to one usize. So 40B instead of 16B. That does seem within the range of "probably doesn't matter" when it comes to memory consumption. And this avoids a double pointer indirection when accessing the metadata.

We could also shrink the header size down (by storing the field sizes as i32 for example) 🤔 I'll make a follow on PR to explore what that would look like

[alamb]

FYI @scovich @mkarbo @PinkCrow007 @superserious-dev

[scovich]

LGTM

[scovich]

One fat pointer, two usize, and a VariantMetadataHeader that should easily pack to one usize. So 40B instead of 16B. That does seem within the range of "probably doesn't matter" when it comes to memory consumption. And this avoids a double pointer indirection when accessing the metadata.

We could also shrink the header size down (by storing the field sizes as i32 for example) 🤔 I'll make a follow on PR to explore what that would look like

[alamb]

In order to avoid conflicts, I am just going to merge this PR and I will be happy to handle any other suggestions / comments as a follow on PR(s).

I would like to unblock additional documentation and testing