c-ffi,go-lockbook: better support for uuids

[steverusso]

Currently in the "C interface" as well call it, file IDs (which are v4 UUIDs) are passed over FFI as C strings (both ways), and they're stored as strings in Go. There are two major changes in this PR:

1. UUIDs will be passed over FFI both ways as 16 byte array values.
2. UUIDs in Go will be a more powerful UUID type instead of a plain string.

Memory Efficiency Throughout

Memory usage for a UUID as a string in Go is 52 bytes:

• the string header is 16 (the pointer and length are each 8)
• the actual hex representation (aka. the length of the string's content) is 36

That's not to mention the overhead of heap allocating and freeing a C string to pass over FFI each way.

Ergonomics, Particularly in Go

For developers consuming the C API as is, it'd be better to have one less heap allocated value to think about, especially when the value in question (a UUID) has a small and known size. But for Go developers, it'd be cool to use a UUID library such as gofrs/uuid instead of plain old strings.

---

Improvements & Summary

UUID values are stack allocated and copied both ways over FFI. They're stored as a uuid.UUID in Go (which is essentially a [16]byte). No heap allocations either way, and the C values in Go aren't even managed by the GC.

Side note: C only passes arrays by pointer, and cbindgen has adjusted for this and will warn you if you try it. Therefore, I had to use the "trick" of wrapping the 16 byte array in a struct. While this is considered bad practice by some, I decided that it'll be fine in this case, which is anytime a standalone UUID needs to be passed over FFI. It looks like:

pub const UUID_LEN: usize = 16;

#[repr(C)]
pub struct LbFileId {
    data: [u8; UUID_LEN],
}

---

Closes #6.