Splitting off fsverity bits

[jeckersb]

Inspired somewhat from #114

I think it would be beneficial to split off the fsverity-specific bits into its own crate, since I could definitely see people wanting to use just the fsverity functionality while not caring at all about composefs.

Related, I don't see that anyone has done rust bindings for libfsverity, so I think it may be worthwhile to do the leg work to get that easily consumable from rust as well. I wouldn't mind taking that on since I've never written a -sys binding crate before and it would be educational just to go through the motions, plus it's a small enough library that it's a good candidate to learn with (or so I hope, famous last words...).

We wouldn't necessarily need to use the libfsverity bindings from any of the composefs code, but it might be worthwhile to test the C impl against any standalone rust impl that we stand up on its own and sanity check that they agree with each other.

Also worth mentioning here for context a previous discussion re: using libfsverity in libcomposefs and why that's problematic.

[allisonkarlitskaya]

One problem with this: we currently define various methods like .to_object_path() on FsVerityHashValue which are very tightly coupled with the repository format...

We might be able to move those to another trait that we define in the composefs crate...

[allisonkarlitskaya]

About libfsverity: I'd prefer not to bind a C library when we already have a working version of the code in Rust...