Architecture-dependent sizes in portable code

There's a problem: if we compile to `AnyCPU`, then we cannot generally determine `sizeof(void*)`, which has to be a constant expression, according to the standard. Same about, say, `size_t` or `ptrdiff_t`, and actually any architecture-dependent types, mostly derived from pointers.

There are two possible strategies of dealing with that.

1. We can forbid using `sizeof` with a pointer and any pointer-sized types in portable code. Our users will have to specify the architecture when compiling a binary that uses these features.

It is possible that this will effectively prevent compiling to `AnyCPU` of the most of C code.

Also, using of such C libraries from external code would be problematic sometimes (the library author will have to distribute versions built for each architecture, which kinda loses the point of Cesium).
2. We can introduce a special architecture-independent compilation mode which will use 8 bytes for any pointer or `size_t`, and generally will prefer bigger object sizes, but will still allow building to `AnyCPU`.

This may be problematic for cases when a C library exposes some .NET interface which operates on pointer types of `IntPtr`: it's unclear how to properly compile that (or if it is even possible).

For now, I am considering going _both_ ways: add a flag to enable (or disable) architecture-independent compilation, and allow the user to specify the architecture that will be used to calculate `sizeof` and whatnot.

**Depends on:**
- [ ] #353,
- [x] #354.