Currently the Terraform Registry returns the zh hash for all platforms,
but not the h1 hash, so the h1 hash has to be calculated separately.
We need to calculate the values for each platform and merge the results.
To avoid multiple downloads and recalculations for each directory, the
results are cached in memory.

In order to update dependency lock files, we need to detect the version
constraints of the providers of the module, but the current Updater
interface can only handle a single file. Therefore, we introduce a new
concept called ModuleContext, which is supposed to provide the Updater
with information of the module that is currently being updated. Changes
to the Updater interface will be addressed later because it requires
massive rewriting.

Note that it does not actually re-implement the resolution of version
constraints in terraform init. It is very simplified for the use we
need. Version constraints only support simple constants and not
comparison operators. Ignore what cannot be interpreted.

Until now, the Updater interface has been implemented statelessly, but
in order to adding a feature for updating the dependency lock file, we
also need the module context. I've only adjusted the interface for now,
but this will also help us to achieve more smart rewriting in the
future. We also need to access the index to cache the hash value of the
provider, which is a global state between modules. I decided to access
the global context via the module context because it is always needed in
combination with the module context. In addition, the option and updater
instances were also moved to the global context, as they have not
changed within the process.

The Terraform dependency lock file (a.k.a. .terraform.lock.hcl) was
introduced in v0.14. While this is fine for simple use cases, there are
may challenges at scale. This is because terraform is based on
per-directory processing, and updating lock files using the official
terraform providers mirror and terraform providers lock commands is very
inefficient.

However, at that time, we avoid supporting for updating the lock file
for the following reasons:

- That the underlying reason for the complexity of updating the lock
  file is due to the lack of capability of the Terraform Registry; it
  does not return the h1 hash value.
- That the Registry protocol could be improved in the future.
- The lock file format implies to support not only providers but also
  modules.
- The lock file format is an implementation detail.
- It was easy to imagine that supporting multiple Terraform versions
  would be hard.

It got worse as time went on:

- With the rise of arm chips, the number of platforms required for
  locking has increased.
- As our infrastructure grown, the number of directories has increased
  accordingly.

However, no progress has been made on this issue in the upstream. So it
is time to reinvent the wheel by ourselves. Calculate hash values in
.terraform.lock.hcl and cache them to be able to update multiple
directories at once.

Initially, we thought of using the key of the zh hash as the platform,
but we found out that it also includes metadata such as manifest.json,
so we decided to use the filename as it is.