[PATCH 10/17] compat/rust_types.h: define rust primitive types

From: Ezekiel Newren <ezekielnewren@gmail.com>

Why Rust primitive types should be used in C:
  * Consistency across languages: Sharing the same type names makes it
    easier to translate and refactor code across boundaries, and search
    history.
  * Clarity and ergonomics: The types f32 and f64 are clearer than
    float and double. The types u64 or isize are easier to write than
    uint64_t, or ptrdiff_t.
  * Explicit intent: Inclusion of compat/rust_types.h signals other
    readers that the code is designed, or being cleaned up, for Rust
    interop.
  * Character types: Rust's char is defined as an unsigned 32-bit type.
    In contrast, C's char is an 8-bit type that is neither signed nor
    unsigned. The u8 type should be used instead of C's char when
    referring to bytes in memory.
  * Keep the FFI boundary precise: When Rust calls into C, the C
    interface should use Rust types exclusively in both functions and
    structs. If a broad refactor would cause too much churn, C stub
    functions may be used as an interim step.

Reasons to avoid c_* types (e.g. c_char, c_long) in Rust:
  * Rust remains precise: Bringing c_* into Rust reintroduces the very
    ambiguity Rust was designed to eliminate. Using only Rust
    primitives keeps our code portable and predictable.
  * One clear contract: Rust should define the interface with precise
    types. C adapts through compat/rust_types.h, ensuring the boundary
    is consistent and easy to audit.
  * Future-proof interop: Other runtimes (Python, Go, Java, Wasm, etc.)
    map cleanly onto Rust's primitives, but not onto c_*. Sticking with
    Rust types makes bindings straightforward and avoids locking Git's
    ABI to C's historical quirks.

Signed-off-by: Ezekiel Newren <ezekielnewren@gmail.com>
---
 compat/rust_types.h | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)
 create mode 100644 compat/rust_types.h