Publish the 51Did client crate so Rust users can verify without a git dependency

[jwrosewell]

What is missing

A Rust consumer can read a 51Did but cannot take part in verifying one from
a published crate.

fodid is on crates.io at 4.5.3, so parsing and offline signature checking
are available. The client that does the two-step verification is new, added
in #33 as the fodid-client crate, and is not published anywhere.

Why it matters now

51Did is about to be launched, and every other language a consumer might
reach for is in a different position:

Language	Package	State
.NET	FiftyOne.Did	on NuGet, though a publish problem is 51Degrees/pipeline-dotnet#387
Node	fiftyone.pipeline.did	on npm, 4.5.37
Python	fiftyone-pipeline-did	on PyPI, 4.5.17
Rust	fodid	on crates.io, 4.5.3, reader only
Rust	fodid-client	nowhere
Java	pipeline.did	nowhere, 51Degrees/pipeline-java#121
PHP	fiftyone.pipeline.did	nowhere, 51Degrees/pipeline-php-did#9

A Rust user who wants to verify a 51Did today has to depend on a git
revision, which is not something to ask of anyone adopting a new feature.

What needs deciding as well as doing

There are two things here, and only the first is mechanical.

Publishing fodid-client. It has no blocking dependency, since it
depends on fodid which is already published. It needs a version, a
crates.io owner, and a CI path. ci/publish-crates.sh already exists and
skips versions that are published, so adding the new member may be most of
the work.

The owid crate question. fodid compiles the OWID source in as a
private module rather than depending on a published owid crate, because
ci/copy-owid-source.ps1 copies it from the owid-rust submodule at build
time. The owid crate that exists on crates.io at 1.0.0 was published by
James Rosewell personally rather than by the organisation. Whether
fodid-client inherits that arrangement or whether it is time to settle the
owid publication properly is a decision for James, not something to
resolve inside this issue.

How to tell it is fixed

cargo add fodid-client works from a clean project, and the example in that
crate's README runs against the live service without a git dependency.

[jwrosewell]

Correction to the second half of this issue. I overstated the OWID question and the answer is better than I implied.

Nothing depends on the owid crate on crates.io, and nothing needs to. owid-rust is a git submodule, ci/copy-owid-source.ps1 copies its source into fodid/src/owid at build time, and every workflow runs that step. The copy is ignored by git so it never lands on main, and the crate manifest lists src/** in include, so the source travels in the published crate.

I checked the published artefact rather than reasoning about it. fodid 4.5.3 on crates.io carries thirteen OWID source files including the LICENSE and NOTICE, and declares no owid dependency. So a consumer taking fodid from crates.io gets OWID compiled in and reaches no personal account.

fodid-client inherits that for free, because it depends on fodid and gets the OWID types through it. Its manifest lists no OWID dependency either.

So there is no decision needed here about the personal publication before this crate can ship. What remains is only the mechanical part, being a version, a crates.io owner for the new crate name, and adding the member to ci/publish-crates.sh.