Generate bindings in xtasks, not in the build script

[yutannihilation]

This is inspired by extendr/extendr#611. I think this repository should also have xtasks.

There are mainly two motivations to separate the bindings generation from the compilation:

1. make the compilation of less troubles like Should not use libR-sys 0.5.0 extendr#580
2. target wasm (I'm not sure if this is even possible, but I think it's a matter of time until not a few package authors and users wish the Rust-powered package on webR)

[CGMossa]

I'm glad you like xtask! I've been working on a libR-sys xtask for a while now... But I was attempting to see, if I could make a new feature with it.

I'll post what I have later..

[JosiahParry]

I would like to help work on this. What would we like the xtask ui to be like?

If i understand correctly the xtask should be ran once per distro and R version. If a machine has more than one version of R available we can build bindings for all versions of R on that distro. We inherit the target from the machine running the xtask.

Should it look something like libr-sys xtask --build --versions 4.2 4.3 4.4 ? Where we can provide multiple versions in the flag?

[CGMossa]

I think a good initial interface, is the one that makes the environment variables of build.rs available as command-line commands.

I don't think you can add versions. What you can do, is add r_home as a path, and then that should be the thing that can be configured (via rig, or whatever the way it is done in CI).

Regarding clap and its Rust requirements, we don't actually need to observe any restrictions like that in xtask. It is a simple binary compiled to help CI for libR-sys. We make sure that publish = false in the Cargo.toml of xtask as well, so that works.

I briefly experimented with what other features a libR-sys xtask should contain, and got these going: https://github.com/CGMossa/miniextendr/tree/main/xtask/ I don't think this is useful, however.