Strict #include dependency ordering

There seems to be a required order of `#includes` when using `openxr_platform.h`.
For example, this compiles:
```
#define XR_USE_PLATFORM_ANDROID
#define XR_USE_GRAPHICS_API_VULKAN
#include
#include
```
This does not:
```
#define XR_USE_PLATFORM_ANDROID
#define XR_USE_GRAPHICS_API_VULKAN
#include
#include
```
You will see many errors about unknown Vulkan types like so....
> error: unknown type name 'VkFormat'

The reason for this is `openxr_platform.h` has a dependency on `vulkan.h` but does not `#include` it. It's generally considered best practice to `#include` or forward declare dependencies directly in the header that's using them so the burden isn't on the user to infer the proper order of includes.
There is some good info in here for anyone new to this concept https://stackoverflow.com/questions/2762568/c-c-include-header-file-order

I would like to understand Khronos's philosophy on this. Also I may just be incorrectly adding OpenXR as a dependency to my project. However looking though https://github.com/KhronosGroup/OpenXR-Tutorials and the `hello_xr` test it seems they also have a strict ordering of the includes.

Reproduce the two include-order examples using openxr_platform.h and vulkan/vulkan.h, starting with the failing case and its unknown VkFormat errors. Compare the header dependency behavior with the examples in OpenXR-Tutorials and hello_xr; done means the expected include contract and resolution of the ordering failure are established.

Written by the indexing model from the issue text.