Support building OpenCloudSaves as a shared library for 3rd party integration

[ShadowApex]

Is your feature request related to a problem? Please describe.
OpenCloudSaves currently only provides an executable binary, which makes it more difficult for 3rd party integration.

Describe the solution you'd like
Provide a shared library build of OpenCloudSaves. Go buildmodes allows exporting Go methods as a C shared library which can be used by 3rd party software to integrate OpenCloudSaves.

Describe alternatives you've considered
One alternative would be to use the CLI provided by OpenCloudSaves to integrate it into other software.

Additional context
I am currently developing a gamepad native game launcher and overlay called OpenGamepadUI as a free and open source alternative. I would love to be able to integrate OpenCloudSaves into it either natively or as a plugin.

[DavidDeSimone]

Will target for 0.17

[DavidDeSimone]

Right now my concept for the API will be to expose a C interface that allow an invocation of the application using our option flags https://github.com/DavidDeSimone/OpenCloudSaves/blob/main/main.go#L14-L23

This will be our stable interface that will follow semver conventions. This way you can embed OpenCloudSave into your application without having to invoke from the command line.

Internally, I try to have the GUI basically "invoke" the command line by using calls to CLIMain, so in general the app internally uses those flags to drive behavior.

[ShadowApex]

That would be perfect!

[DavidDeSimone]

That would be perfect!

I couple of other issues I am thinking through:

1. OpenCloudSave currently compiles and distributes a copy of rclone to perform the actual syncing. There are a couple of solutions I can think of for this:
   a. Require users of opencloudsave.so to provide an rclone for usage
   b. Try to bundle rclone into open cloud save (not sure of the difficulty here, it may be harder than I initially anticipate)
2. On windows, OpenCloudSave requires a WebView DLL and WebView2 to be installed by the end user. This is all currently handled by our MSI - these requirements would end up passed on to the users of opencloudsave.so
   a. I don't know of another way around this - but I imagine it won't be a deal breaker for most applications, since they can just copy our install flow/distribution from how we build our MSI.

[ShadowApex]

I think it's reasonable to require the integrator to bundle or make their package depend on rclone themselves if they're using the shared library. Maybe OpenCloudSave could also expose an interface to specify the path to rclone if the integrating application has rclone in a custom directory?

For OpenGamepadUI, since it's Linux-only, I was just planning on adding rclone as a dependency after integrating OpenCloudSave.

[DavidDeSimone]

I think it's reasonable to require the integrator to bundle or make their package depend on rclone themselves if they're using the shared library. Maybe OpenCloudSave could also expose an interface to specify the path to rclone if the integrating application has rclone in a custom directory?

For OpenGamepadUI, since it's Linux-only, I was just planning on adding rclone as a dependency after integrating OpenCloudSave.

Yeah, this sounds reasonable to me - I like the idea of exposing a hook for a user to specify the path to the rclone they want to use. I might expose that in the GUI layer as well.