Support reading skims from Parquet files, in addition to OMX

[jpn--]

Closes #970

This pull request adds support for reading skim files in Parquet format in addition to the existing OMX format. The changes allow both dense and sparse Parquet files to be auto-detected and mixed with OMX files in the same workflow, with no changes required to existing settings other than using the .parquet or .pq file extension. The implementation includes updates to documentation, configuration, and the skim loading logic, ensuring compatibility with legacy workflows and Sharrow 2.16+ features.

Support for Parquet skim files:

• Added logic to auto-detect and load skim files in Parquet format (with .parquet or .pq extensions) alongside OMX files. Parquet files can be dense or sparse and are supported by both legacy and Sharrow-based loaders. [1] [2] [3]
• Updated documentation and configuration docstrings in network.py to describe Parquet skim file support and usage. [1] [2] [3]

Skim data loading and handling:

• Refactored the skim dataset loading logic to merge data from multiple sources, handle time periods, and fill zeros for missing sparse OD pairs to maintain compatibility with legacy behavior.
• Ensured that Parquet-backed datasets are properly handled when storing skims in shared memory, including closing file handles and supporting dask-backed data.

Codebase and API updates:

• Added and documented new internal helpers for time period detection, masking, and zero-filling for Parquet files.
• Updated the skim dictionary factory to cache Parquet file metadata and ensure consistent zone ID handling across mixed input files. [1] [2] [3]
• Clarified and expanded docstrings to reflect support for both OMX and Parquet skim files throughout the codebase. [1] [2]

[jpn--]

@amsamimi I cannot formally make you a GitHub "reviewer" on this unless you accept the invitation to join the ActivitySim org, but since this addresses the issue you opened, you should definitely review it anyway 😉

[amsamimi]

A Sharrow-enabled smoke test completed successfully using the following configuration:

households_sample_size: 200
num_processes: 1
sharrow: true
models:
  - initialize_landuse
  - initialize_households
  - compute_accessibility

[jpn--]

Thanks for reviewing this @amsamimi.

At our recent engineering meeting, we also discussed that functional correctness is a necessary but not sufficient criteria for acceptance of new features; performance impacts are also relevant. While your smoke test is valuable, it would also be important to know if the new code is performing adequately. For this PR it may be possible to check that simply from the logs of the smoke test -- the main effect is at skim loading, which happens similarly for a full model run or this tiny piece of one. Can you look and see what the time needed to load parquet skims is, and compare against the equivalent OMX time on your same underlying data?