[Variant] Define and use unshred_variant function (#8481)

# Which issue does this PR close?

- Closes #8336
- Closes #8334

# Rationale for this change

The `VariantArray::value` method was really inefficient but had quietly
crept into important code paths like `variant_get`. Since the complex
and inefficient code was in support of variant unshredding, we should
just add and use a proper `unshred_variant` function (which uses row
builders like the other variant manipulating functions).

# What changes are included in this PR?

* Define the new `unshred_variant` function, which does what it says. It
supports all the types `typed_value_to_variant` supported, plus Time64
and Struct as a bonus. The former because it was ~10LoC and the latter
because it demonstrates the superiority of this new approach vs. e.g.
#8446
* Wire up `variant_get` unshredding path to call it, which immediately
benefits from all that function's existing test coverage.
* Update the variant_integration test to `unshred_variant` instead of
looping over rows calling `value(i)`.

# Are these changes tested?

Yes, a bunch of variant integration tests now pass that used to fail.

# Are there any user-facing changes?

Several new pub methods. I don't think any breaking changes.

Author: scovich

parquet-variant-compute/Cargo.toml

@@ -38,6 +38,7 @@ indexmap = "2.10.0"
 parquet-variant = { workspace = true }
 parquet-variant-json = { workspace = true }
 chrono = { workspace = true }
+uuid = { version = "1.18.0", features = ["v4"]}
 
 [lib]
 name = "parquet_variant_compute"

parquet-variant-compute/src/lib.rs

@@ -41,6 +41,7 @@ mod from_json;
 mod shred_variant;
 mod to_json;
 mod type_conversion;
+mod unshred_variant;
 mod variant_array;
 mod variant_array_builder;
 pub mod variant_get;
@@ -54,3 +55,4 @@ pub use from_json::json_to_variant;
 pub use shred_variant::shred_variant;
 pub use to_json::variant_to_json;
 pub use type_conversion::CastOptions;
+pub use unshred_variant::unshred_variant;