CPU architecture constants

Currently lscompute uses the uname syscall to [get the machine name](https://github.com/canonical/lscompute/blob/df741570ab1e3df946a63311a180aba182c561c1/pkg/machine/cpu/architecture.go#L13-L19) (a.k.a. architecture).

On the engine manifest side we want to use the architecture constants that are commonly used in the snap ecosystem. This follows the debian naming.

The mapping from uname/Linux kernel architecture name to Debian architecture name is not one-to-one. As an example see [here](https://wiki.debian.org/ArchitectureSpecificsMemo#line46) how many different Debian architectures the `uname -m` architecture `x86_64` maps to.

If we do this translation we will need to choose a subset that we support and can confidently translate.

An alternative method would be to use the `dpkg --print-architecture` command to find the Debian arch of the current system, but that might not work correctly from a snap - tbd.

A non-exhaustive list of possible values returned by `uname -m` can be found [here](https://stackoverflow.com/questions/45125516/possible-values-for-uname-m).

Start in pkg/machine/cpu/architecture.go at the uname-based machine-name lookup referenced in the issue. Review the Debian architecture mapping and determine which architectures can be translated confidently, including whether dpkg --print-architecture is usable in a snap. Done means the supported mapping and manifest constants are agreed and the chosen approach is implemented.

Written by the indexing model from the issue text.