gio: manually implement content_type_guess

[davidmhewitt]

Related: #1257

In C, g_content_type_guess supports passing NULL to the data parameter which makes it guess the content type based on the filename only.

So, add a manually written content_type_guess allowing Option for the data parameter. This is a stopgap until gir can generate the optional parameter for these cases.

This is an API break in some cases, but should continue to compile in most cases.

[sdroege]

Not sure if it wouldn't be better to implement the other function manually and have it take an Option<&[u8]> as parameter.

@bilelmoussaoui do you have a preference?

[sdroege]

Alternatives would include changing the generation of the content_type_guess to allow passing Option<&[u8]> but this would be an API break.

If you make it impl Into<Option<&[u8]>> then (almost all?) existing code will continue to compile, but it's technically still API breakage of course.

[bilelmoussaoui]

The actual solution is to fix gir so that all the broken functions are generated properly.

Adding a function deviates further from such fix, at worst implement it manually to fix the behaviour despite the API break and you can call into ffi manually on your app/lib side until we do a breaking api release

[sdroege]

until we do a breaking api release

We also decided that we don't consider nullability fixes as unacceptable breaking changes

at worst implement it manually

So let's manually implement this function for the time being until someone has the time and motivation to fix gir :)

[davidmhewitt]

I've updated this PR to replace the generated content_type_guess function with a manually written one that allows using an Option for the data parameter.

This can be a stopgap until gir generation for these types is fixed.

[sdroege]

As work on this is underway in the code generator (gtk-rs/gir#1622), let's see if we can get that merged relatively soonish.

[sdroege]

6 months later, the answer is no I guess. So let's get this in for now :)