Dynamically load libudev in linux-hidraw backend

[falkTX]

This PR allows applications using hidapi with linux-hidraw backend to not have any direct dependencies, making binaries more portable and easier to build.

For the loader file I used the same license as libudev (LGPL-2.1-or-later), and copied their way of doing the license header too.
The file is included in-place, just to keep the diff as small as possible.

[mcuee]

The build failed under Ubuntu and Arch Linux.

[falkTX]

The build failed under Ubuntu and Arch Linux.

Related to more strict warnings, likely fixed now.

[mcuee]

The build failed under Ubuntu and Arch Linux.

Related to more strict warnings, likely fixed now.

Not yet...

[falkTX]

The build failed under Ubuntu and Arch Linux.

Related to more strict warnings, likely fixed now.

Not yet...

I built locally with the same pedantic flags and pushed another try.

[Youw]

I don't mind the idea of having libudev loaded dynamically in runtime, but I can't agree that the current aproach is best for that. A few points I'd ask to change if I where to accept it this way:

• licence shouldn't derive from libudev license - we don't copy-paste their code, and HIDAPI uses a bit different licencing sceme, and the new source that becomes a part of HIDAPI would potentially restrict its users;
• including the .c file for this purpose looks a bit ugly, and the name libudev.c suggests that it actually is (i.e. implements) libudev, but in fact it is only a wrapper; what is best instead - have a hidapi_libudev_wrap.h, and all functions inside should be either static or inline;
• the C() macro... I checked - it is a valid C, but the fact that I had to go and double-check suggests that it looks like something that might break; HIDAPI_UDEV_RESOLVE wouldn't raise any naming suspicious
• RTLD_GLOBAL - that is a code smell to use it here, where passing the _lib (or rather udev_lib_handle to dlsym) explicitly is what I'd expect
• no dlclose which is technically a resource leak if HIDAPI itself is ever to be dynamically loaded

---

At the end of the day - I'd be much happier to see a more common way of dynamically loading a library during the initialisation, saving and using function pointers explicitly and unloading a library during the hid_exit, e.g. like we did it for windows backend.

Yes that would cause a lot more changes in linux/hid.c - but that's absolutely fine.

[Youw]

the documentation and CI scripts also needs to be updated - now the libudev-dev no longer required and only the libudev1 is needed

[falkTX]

That is all very fair, I mostly did this change as a way to get my cross-compilation builds working and decided to push it upstream because why not.

You have good points for something that would be integrated officially in hidapi, but sorry to say my needs are covered already as-is, the steps you mention make sense but sound like it would be quite a bit more work than I am willing to spend just for a small feature.

If you think the feature is worthwhile, take all the code here to adapt freely under any license, I give written consent.
This is as far as I go though, perhaps someone else can take over now.
Or otherwise feel free to close the PR too, I can understand that too.

[Youw]

Thanks for the contribution.

I'll leave it be for now, in case anyone wants to catch up.