Use the "cargo metadata" command instead of manipulating paths directly

[Michael-F-Bryan]

No description provided.

[hannobraun]

Thank you, @Michael-F-Bryan! Looks reasonable. I'll take a closer look on Monday.

[Michael-F-Bryan]

I found a second issue which is related to the assumptions we make about paths and directory structures.

When my projects all have a common prefix (e.g. fj-) I'll typically call the crate fj-foo and put it in the crates/foo/ folder, however because we assume the compiled *.so is the named same as its folder, I was getting a bunch of "target/debug/libfoo.so not found" errors when it is actually compiled as .../libfj_foo.so.

My second commit switches the naming logic to use a package's name as derived by cargo metadata (i.e. the thing in your Cargo.toml). The behaviour is identical for the models in this repo, but now it also handles the renamed directories case.

[hannobraun]

Thanks again for the pull request, @Michael-F-Bryan!

I've left some comments about the error handling. Feel free to address this in a follow-up commit, if you want. If not, I will open an issue to track it shortly.

[hannobraun]

Let's remove this conversion. The function doesn't need to return io::Error. It can return a custom error type that covers all its failure modes. (The crate already depends on thiserror, so we don't even need an additional dependency.)

[hannobraun]

Let's use a more appropriate custom error type here. We can probably reuse whatever Model::from_path will end up returning.