Allow defining intended scope of AnyCPU

Inferring that Pack=4 on x86 when there is no explicit packing sounds reasonable to me.

That being said, it seems odd to me that if the metadata adds support for more architectures, it could mean that CsWin32 could suddenly lose more types for AnyCpu projects. It feels weird that coverage of CsWin32 depends on the metadata having "less coverage" of various architectures.

One way CsWin32 could mitigate this would be to allow AnyCpu projects to specify a set of architectures it will actually support. This way if the metadata adds support for architecture X, AnyCpu projects won't suddenly lose some of the API because architecture X has some weird one-off definitions. I think this extra option would allow CsWin32 to cover these 3 main use cases:

1. Use Cpu-Specific to get access to full API
2. Use AnyCpu with limited Architecture set to get access to the api that is common to all supported architectures
3. Use AnyCpu with no limits on architectures to get the truly common API for everything that metadata supports

Originally posted by @marler8997 in https://github.com/microsoft/win32metadata/issues/613#issuecomment-901320613

No files, tests, or entry points are named. Start by tracing how CsWin32 determines architecture coverage for AnyCPU projects and how project options are represented; done means an AnyCPU project can explicitly select its supported architectures without unexpectedly losing APIs.