Refactor determining Host triple to use `--unit-graph` instead of rustc

[volks73]

As mentioned in #113, determining the default Host triple using the rustc --version --verbose command is not ideal, but there is currently not a way to determine this information directly from Cargo. The --build-plan option could have been used, but it is being removed and replaced with the --unit-graph option instead. It will take a while for the --unit-graph option to stabilize, but once it is available, the rustc --version --verbose implementation should be replaced with the --unit-graph option. It is also possible that through the development of the --unit-graph option, the cargo metadata and related cargo_metadata crate may also be used to obtain the needed information.

This is mostly a marker/reminder to refactor.

[roblabla]

Just a small nit: Determining the host triple isn't the problem (that works pretty well by asking rustc to report its triple). The problem is, it's possible to change the default triple to be something other than the host by setting the default-triple cargo configuration, and there's no clean way to get this. Using --unit-graph would allow us to reliably see which target cargo used to build.

[volks73]

Is --unit-graph going to be needed? Based on discussions in #127 and #126, the Host triple can be determined from rustc --print cfg and possibly the usage of the rustc-cfg crate, both of which are already available in stable toolchains.

The parsing and determination of the Host triple still needs to be refactor, but maybe not with the unstable --unit-graph option.

[roblabla]

There's one small issue. rustc --print cfg doesn't give the whole TargetName, only the components. It's not trivial to reconstruct the target name from the components (i586 vs i686 targets for instance), and might even be impossible if we take custom targets into account. Not having the whole TargetName means we wouldn't be able to reliably fill in TargetTriple reliably.

Furthermore, rustc --print cfg is actually slightly problematic here. We'd ideally need to run something akin to cargo rustc -- --print cfg (to let cargo apply the default target config) but this will cause cargo to build all the deps before running our command, and so will interact poorly with --nobuild.

So I don't think --print cfg is the solution here.