Set Multi-Arch: foreign on all Architecture: all packages

[geofft]

There is an edge case where a pre-multiarch Architecture: all package should be considered as for the native architecture only: when it re-exports an architecture-relevant interface from one of its dependencies. (For instance, libatlas-dev is Arch: all because it only includes headers, and depends on libblas-dev which ships the library; someone installing libatlas-dev as a dependency for an amd64 package or a build-dep for an amd64 build is not going to find libblas-dev:i386 helpful.)

Because of this edge case, by default, Architecture: all packages are considered as actually only being installed for the native architecture, and require all their dependencies to come from the native architecture, unless you set Multi-Arch: foreign. When you do, their dependencies and reverse-dependencies can come from any architecture, and they can be used as cross-build-dependencies.

This edge case is not relevant for, I think, any of the Architecture: all packages in Debathena. In particular it is irrelevant for things like the major metapackages (debathena-workstation etc.) or for just about any config package, unless we're doing something weird with compiling binary files in the postinsts or something.

In practice, for people just using a single arch, it doesn't matter much. But I think the big case this affects is converting a Debathena machine in-place from one architecture to another (e.g., i386 to amd64). So long as debathena-workstation isn't Multi-Arch: all, the package is broken unless _all_ of its dependencies are installed from the native architecture, so switching the machine's native architecture gets a lot more complicated immediately for no good reason.

See  my comment on config-package-dev#2 and the links in that PR, notably  MultiArch/Hints "set Multi-Arch: foreign" on the Debian wiki, for more details.

We should in theory go through all Arch: all Debathena packages, make sure they're not doing anything weird with compiling things in postinsts or depending on arch-specific libraries. (Most Debathena metapackages or config packages should not care about libraries; those that do, like debathena-athena-libraries, should be Architecture: any anyway so that you can install both sets of libraries if you want.)

This isn't very high priority, but if something comes up where in-place architecture switches become relevant, then this will become high-priority.