[PROF-4780] Breaking change: Change FFI File struct to contain a Buffer instead of a ByteSlice

[ivoanjo]

What does this PR do? + Motivation

In #30 we added the ddprof_ffi_Buffer_from_byte_slice function to allow FFI users to provide their own data to be reported using the ProfileExporterV3 (via ddprof_ffi_ProfileExporterV3_build).

Thus, if one wanted to report some data, it first converted it from a ByteSlice into a Buffer, and then invoke libddprof with it.

Here's a (simplified) example from the Ruby profiler:

  ddprof_ffi_File files[1];
  ddprof_ffi_Slice_file slice_files = {.ptr = files, .len = 1};

  ddprof_ffi_Buffer *pprof_buffer =
    ddprof_ffi_Buffer_from_byte_slice((ddprof_ffi_ByteSlice) {
      .ptr = /* byte array with data we want to send */,
      .len = /* ... */
    });

  files[0] = (ddprof_ffi_File) {.name = /* ... */, .file = pprof_buffer};

  ddprof_ffi_Request *request =
    ddprof_ffi_ProfileExporterV3_build(exporter, start, finish, slice_files, timeout_milliseconds);

  ddprof_ffi_Buffer_free(pprof_buffer);

This approach had a few downsides:

1. It copied the data to be reported twice. It would be first copied into a Buffer, and then inside ddprof_ffi_ProfileExporterV3_build it would be copied again.

2. Callers manually needed to clean up the Buffer afterwards using ddprof_ffi_Buffer_free.

After discussing this with @morrisonlevi, we decided to go the other way: change the File to contain a ByteSlice directly.

This avoids the extra copy in (1.), as well as the caller needing to manage the Buffer objects manually in (2.).

This is a breaking API change for libddprof FFI users.

How to test the change?

Validate that any FFI user (such as examples/ffi/exporter.cpp) can still successfully report data after the update.

I've validated locally with the Ruby profiler (PR incoming at some point); I could not build examples/ffi/exporter.cpp due to unrelated reasons -- I'll tackle it separately from this PR.

Update: Pushed a couple of commits to update exporter.cpp, and confirmed it still works fine.

[morrisonlevi]

Good work! After merging this in, can you see if it causes any conflicts with #32 and fix them for Paul if so? If not, ping me and I can do it.