Add support for multi-output operations

[versi-tech]

There are some operations like findTrim or project providing multiple outputs as a result. Current implementation lacks API exposing it to the client.

Similarly to other high-level language bindings to libvips - this PR suggests dealing with multiple outputs via generic key-value structure - Map from JVM.

As a result - VImage operations providing multiple outputs return Map<String, VipsOption> instead of just a first output value. I've decided to suggest usings maps instead of simpler structures like list due to 2 reasons: consistency with other bindings & efficiency of seeking the results (direct access).

[lopcode]

Thanks for the PR!

This looks like a great improvement on the face of it. There are a couple of details like the generic option I want to have a think about, but I'll review and maybe tweak in the next day or two.

[versi-tech]

Thanks for the PR!

This looks like a great improvement on the face of it. There are a couple of details like the generic option I want to have a think about, but I'll review and maybe tweak in the next day or two.

Thanks! Yeah - generic option approach was simply my first idea, but I guess there might be other ways. Thanks for looking into it - just FIY - I'm open to work on adjustments as per your suggestions on my own as well.

[lopcode]

Playing around with this, this week. I think we can keep VipsOption generics-free, plus Palantir's JavaPoet supports record types so we can maybe wrap multiple required outputs in to a helper record with nicely named properties.

[lopcode]

Ended up going for the record based approach - the required outputs are known at generation time, so we can make a container record for the outputs including their original types, and parameter names according to the docs.