True Template Support: Enables access to all parameters within GRIB2 files

[noritada]

Motivation

GRIB2 files contain various information beyond the grid point values, latitude/longitude data, and timestamps that most users require.
Templates comprehensively implement this information for diverse patterns.

The current template support in the grib crate is strictly internal, serving to extract parameter values necessary for reconstructing packed grid point values and performing latitude/longitude calculations.
Users can only access values for a subset of parameters; many parameters are either not loaded or, even if loaded, remain unexposed externally and inaccessible to users.
I have used the term “template support” as a way to articulate what patterns are supported.
This is because the initial stage focused heavily on the fundamental task of implementing decoding methods for data packed in various formats to make the data usable.

Even with this implementation, it should suffice for over 90% of users who likely only want to read the time, latitude/longitude, and value data for each grid point.
However, in this state, users have limited options when, for example, data is unsupported.
Furthermore, those who want to thoroughly examine every corner of the data to ensure they understand all the parameters they truly need will find this insufficient.

Properly implementing the template and making the data accessible to the user resolves this issue.
For example, even if the decoding process for the packed data is not implemented, the parameters themselves can be read.
Furthermore, it becomes possible for the user to implement the decoding process on their own side.

This implementation will require significant effort across multiple versions.
While GRIB2 templates contain various parameters, these are merely defined in meaning without assigned names.
Therefore, names must be assigned to all parameters across all patterns.
Furthermore, existing ad-hoc internal implementations must be replaced.
And the data's polymorphism must be properly represented.

Support for local templates will be deferred to future implementations and is outside the scope of this effort.

Proposed Solution

• Assign names to all parameters in every pattern and clarify their meanings
• Read all parameters from any byte sequence pattern
• Expose all parameters to the user

Additional Context

• basic toolkit for parameter reading
• basic toolkit for parameter display
• definition of parameter names and meanings, specifics of data reading and display
  • section 0
  • section 1
  • (section 2)
  • section 3
  • section 4
  • section 5
  • section 6
  • section 7
  • (section 8)
  • template 1.x
  • template 3.x
  • template 4.x
  • template 5.x
• CLI