Refactor artifact architecture and url

[runesoerensen]

This PR builds on the work completed in #216, and focuses on:

• Decoupling the Go specific "architecture" format from the platform information stored in the inventory. It does so by:
  • Removing the combined Artifact#architecture field (e.g. linux-amd64) in favor of two new fields, os and arch, with values that we explicitly define (rather than relying on Go's terminology).
  • In particular, that now means the arch field is set to x86_64 rather than the Go idiomatic/specific amd64 naming.
    • Similarly, when adding support for more archs and OSs, we'll like prefer values like aarch64 and macos (e.g. values that map to Rust's arch and os rather than Go's arm64 and darwin terminology).
    • This will help us compare these values later, and make it easier to adapt the code for use by more buildpacks.
• Setting the artifact download URL in the inventory.toml. This eliminates the need to maintain/use Go-specific logic related to the filename, as well as constructing the download URL in code, for consumers of the inventory - this is now only necessary when parsing the Go feed information.
  • It also switches the download URLs to go.dev/dl/{filename} instead of dl.google.com/go/{filename}. We've previously used https://dl.google.com/go, but that target is an implementation detail and subject to change.
  • Using the canonical/official go.dev/dl/{filename} URLs enables us to include the artifact URL in our inventory.toml -- with a reasonable expectation that the upstream will continue to redirect to the appropriate and currently available target endpoint (when/if it changes again).

Finally, Inventory::resolve now filters artifacts based on the current OS and ARCH prior to resolving artifacts that satisfy the version string requirements. This is based on the assumption that the target platform/runtime will always be the same as the build platform/environment executing the buildpack.

While adding support for updating and parsing artifacts for other OS and ARCH combinations than linux/x86_64 is outside the scope of this PR (particularly so the inventory.toml field changes can be reviewed on their own, without adding more artifact entries), this seems to be the appropriate time and place to introduce this constraint - ensuring the new fields are also being utilized in the code that consumes our inventory.