chore: remove parquet dependency from parquet_derive

[ByteBaker]

Which issue does this PR close?

• Closes parquet_derive does not need to depend on parquet #1002.

Rationale for this change

parquet_derive is a proc-macro crate, but it currently has a normal dependency on parquet. This causes parquet and its dependency graph to be compiled for the proc-macro host even though the macro only needs to emit references to Parquet APIs.

As discussed in the issue, derive crates such as serde_derive avoid depending normally on the runtime crate. The generated code is instead resolved against the consumer's direct dependency.

What changes are included in this PR?

• Replaces compile-time use of parquet::basic::Type with a private physical-type classifier.
• Keeps generated ::parquet::... paths unchanged.
• Removes parquet as a normal dependency of parquet_derive.
• Retains parquet as a dev-dependency for doctests.
• Removes the now-unnecessary extern crate parquet.

Are these changes tested?

Yes. Ran:

• cargo test -p parquet_derive passed.
• cargo test -p parquet_derive_test passed.
• cargo clippy -p parquet_derive --all-features -- -D warnings.
• cargo fmt --all -- --check.
• cargo tree -p parquet_derive --edges normal, confirming its normal dependencies are now limited to proc-macro2, quote, and syn.

Are there any user-facing changes?

None.

[ByteBaker]

@alamb please review.

[Jefffrey]

int96 disappears?

[ByteBaker]

Sorry for not explaining this.

The match arm comes from self.ty.physical_type(), but the said method never originally returned INT96 or constructed it inside the implementation.

Which is why I did not add an Int96 variant in the new (private to parquet_derive) PhysicalType.

enum PhysicalType {
    Boolean,
    Int32,
    Int64,
    Float,
    Double,
    ByteArray,
    FixedLenByteArray,
}

At the same time, I also noticed that INT96 has been marked deprecated inside parquet/src/basic.rs, making it unlikely that anyone in the future would construct this type.

enum Type {
  INT96 = 3;  // deprecated, only used by legacy implementations.
}

Which convinced me that this can be safely removed. All it does is remove an unreachable branch.

What do you think?

[Jefffrey]

makes sense to remove if it was already unreachable, thanks

[Jefffrey]

thanks @ByteBaker

[ByteBaker]

Happy to contribute.