Draft: Replace old C code with current huacnlee/rucaptcha Rust code

Ok before you say anything, I don't expect this to be merged but I wanna just put the alternative on record share some ideas I think are good.

This is based on the same project as the C code that was used in this Elixir library, but it is now Rust, however, the captchas the new code generates seems much stronger.
I just took the project, removed all the Ruby code I didn't need and made a main function to output the same thing as the old C code, in this repository.

I think the new captchas look much stronger and may be harder to crack than the current easy ones right out of the box.

• Current captcha:
• New captcha:

You may say requiring Rust seems like a showstopper because not every one uses captcha or has open registrations, and I would agree with that, however I propose an alternative:

1. Fork my fork into this GitLab
2. Setup CI to cross compile it to every supported platform
3. Edit this library to check for the platform it's running on (x64, ARM, etc) and download the appropriate pre-compiled version from here (kinda like how the Pleroma OTP is downloaded), those should be stored with sha512 hashes or something and the list should updated manually ofc.
   I think the tricky part about this would be check for GNU LibC or MUSL. Maybe just try compile some code like this and check the return code from make or the compile, if it's not 0, it's MUSL?

#include <gnu/libc-version.h>
#include <stdio.h>
#include <unistd.h>

int main() {
    printf("%d.%d\n", __GLIBC__, __GLIBC_MINOR__);
    return 0;
}

4. Keep the old C code around, if it's not a supported platform, fall back to it. This could mean you can't really increase the number of characters in the captcha, but surely this can be made configurable or detectable somehow? The output of both C and Rust can be changed to be more robust.

I'd also like to show another person had the same idea as me, and used a Go captcha library instead.
This is what his captchas look like:

The main takeaway here is that modifying the existing C code is way harder than it would be in either of those implementations, and they may also get improved/updated upstream and we could just use that, but custom code can also be added downstream much more easily.

Anyway, this is just an idea not a serious merge request, let me know if any of this makes sense.