Deprecate methods relying on Hadoop classes when alternatives using more generic Parquet interfaces are available

Deprecate methods relying on Hadoop classes when alternatives using Parquet interfaces are available. This would allow for fully decoupling from Hadoop for simple read/write (and potentially rewrite) operations in the future, where we are now only on track to decouple from hadoop-client-runtime in the near future.

We could decide to still keep Hadoop methods available through convenience classes in their own Hadooped module, but for core read/write logic to be available without forcing users into the Hadoop dependency, we will need to fully strip the core readers and writers of these references.

**Reporter**: [Atour Mousavi Gourabi](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=amousavigourabi) / @amousavigourabi
#### Related issues:
- [Create specialized HadoopParquetWriter](https://github.com/apache/parquet-java/issues/2854) (is blocked by)
- [Create specialized HadoopParquetReader](https://github.com/apache/parquet-java/issues/2855) (is blocked by)

_{**Note**: *This issue was originally created as [PARQUET-2381](https://issues.apache.org/jira/browse/PARQUET-2381). Please see the [migration documentation](https://issues.apache.org/jira/browse/PARQUET-2502) for further details.*}

Start with the migration documentation linked in the issue, then read the related specialized HadoopParquetWriter and HadoopParquetReader issues. Identify the core read/write methods that rely on Hadoop classes and the available generic Parquet interfaces. Done means those methods are deprecated or decoupled as described, with the Hadoop-specific path isolated without forcing the dependency on core users.

Written by the indexing model from the issue text.