Add support for provider namespace

[minamijoyo]

Fixes #99, #65

The current implementation of tfupdate provider <PROVIDER_NAME> uses the <PROVIDER_NAME> argument as a key for the required_providers block. To support namespaces, we also need to check the source attribute. The most important point is that the key can be almost any string but cannot contain /. Thus, if the argument contains /, we can assume that the user intends to use namespaces and check the source attribute. To maintain backward compatibility of tfupdate, when namespaces are omitted, hashicorp/ should not be implicitly assumed.

In addition, if a version is omitted when updating providers, we use the namespace as a GitHub namespace and fetch the latest version. This is based on some implicit habitual assumptions and may not be accurate. Still, we continue to use GitHub as a release source because we rely on GitHub's redirects when namespaces are omitted.

One concern is that it is unclear how long the legacy terraform-providers/ org redirects will be maintained. I will take this opportunity to switch it to the current hashicorp/ org.

Thus, namespaces must be explicit for legacy partner providers if all of the following conditions are met:

• The tfupdate provider command does not explicitly specify the namespace.
• The tfupdate provider command does not explicitly specify the version.
• Redirected from legacy terraform-providers/ org to partner org on GitHub.
• Not hosted under hashicorp/ org on GitHub.
• Not redirected from hashicorp/ org to partner org on GitHub.

This could be a breaking change to a small number of partner provider users, but the impact is limited, so it has been fixed how it should be.

$ cat main.tf
terraform {
  required_providers {
    github = {
      source  = "integrations/github"
      version = "5.38.0"
    }
  }
}

$ tfupdate provider integrations/github main.tf

$ cat main.tf
terraform {
  required_providers {
    github = {
      source  = "integrations/github"
      version = "5.39.0"
    }
  }
}