- printer.h uses `uint64_t`, so it needs to include something that ensures that type is defined. `HalideRuntime.h` is probably the right choice (since it always transitively includes `runtime_internal.h` when compiling runtime.

- HalideBuffer.h should completely elide itself when `COMPILING_HALIDE_RUNTIME` is defined, for a subtle reason: some compilation environments require that all .h files can be compiled 'standalone' -- ie, they include all prerequisites and can be included in any order. As it turns out, HalideBuffer.h has a previously unnoticed glitch that is now being caught by this:
    - It includes both `<cstring>` and `HalideRuntime.h`
    - but when `COMPILING_HALIDE_RUNTIME` is defined, `HalideRuntime.h` includes `runtime_internal.h`, which assumes that no std headers are included
    - as it happens, `runtime_internal.h` defines `strstr()` and `strchr()` in a way that doesn't match the std headers (they both return non-const `char *`, perversely enough) and we get a compile error for mismatched function prototypes

I think the neatest solution here is to just skip the entire contents of `HalideBuffer.h` in this situation, since none of its contents should ever be used inside the Halide runtime. (I could work around this situation on the google side by loosening the 'must be able to compile on its own' requirement in this case, but IMHO it's a good check and one that is worthy of keeping.)

The fact that our function prototypes are a mismatch for the 'correct' ones could be debated; IMHO our 'wrong' definitions are safer that the std and should be kept.