Handle more data marshaling in generated code?

[craiglabenz]

Right now, for a function like this in C:

char* my_function(char* value) { ... }

ffigen generates bindings like this:

Pointer<Char> myFunction(Pointer<Char> value) { ... }

Requiring calling Dart code to look like so:

final results = bindings.myFunction(
  'a string'.toNativeUtf8().cast<Char>(),
);

print(results.cast<Utf8>().toDartString());

If instead, ffigen generated the following code:

String myFunction(String value) { 
  final result = nativeFunction(value.toNativeUtf8().cast<Char>());
  return result.cast<Utf8>().toDartString();
}

then using ffigen would become tremendously more straightforward.

[dcharkes]

There are multiple issues with this approach.

1. char* could be encoded in multiple ways: UTF-8, ASCII, ... (I believe UTF-8 is the most common, but I've used ASCII before with C libs.)
2. char* could be null (0x0) terminated or there could be a length param. (I believe null-terminated is more common.)
3. The life-time and memory ownership of char* arguments is undocumented.
   a. Does the callee take ownership and free it?
   b. Or, can the caller free it immediately after the call returns? (I believe this to be the most common.)
   c. Or, can the caller only free it after some other C function has been called?
4. The memory ownership of char* return values is undocumented
   a. Does the caller take ownership and free it?
   b. Does the callee free it after some other C function has been called (for example in SQLite when going to the next row in a query result).
5. A char* could be just a byte-array instead of a string.

Now, hopefully a single library, and single FFIgen invocation should make a consistent set of choices. However, if that's not the case we'll have to start using regex filters to apply certain behavior to certain C functions.

Duplicate of #508.