Some languages already use that for the purpose, but it's an ill fit. It's meant for the internal parser of the language, so you need to parse C code (even if it's just the header file syntax). And it wasn't created with FFI in mind, in the first place.
What I propose is a file intended for others wanting to FFI, and thus trivial to parse (could be a schema for a format with ubiquitus parsers, like XML, JSON, YAML, TOML, and co).
That would have the benefit of:
(1) being cross-language (every language that exposes functions with C calling conventions could produce such a file to allow others to interface with it.
(2) being trivial to parse and integrate with ffi facilities of different languages (e.g. ctypes)
(3) being extensible beyond the C-header files give (e.g. metadata about usage, or valid int ranges, even function documentation, etc).
Yup, there's also the more common approach of implementing extensions in C (or equivalent), possibly with an intermediate language.
For example, Cython is a much more scalable approach, in my experience, than attempting to describe the interface in Python and using a libffi-style binding.
See: Vulkan's vk.xml
Better FFI's generate their definitions from such header files, called header parsers. (based on some CPP code). This problem was solved in the 80ies, but I guess forgotten by now.