feat: add miden-verify to toolchain 0.14.0

[saimeunt]

This PR adds Miden Verify a CLI responsible for verifying Miden accounts and notes to midenup as a verify component accessible through miden verify.

The miden-verify CLI is just a wrapper performing API calls to a "Verification API" configurable via --verifier-url.

The underlying API doing the actual verification is documented here: https://walnutlabs.notion.site/Public-Miden-Contract-Verification-API-3113cefbe64b807eaa92d3c673bde0bc

At the moment a PoC implementation of this API has been released as part of the Miden Playground and is leveraged by the MidenScan explorer to display Rust source codes of verified accounts and notes.

An ongoing work is in progress to extract this verification API out of the Miden Playground project and release it as a set of self-hostable services codenamed Miden Sourcify.

@lima-limon-inc This PR ends up being exactly the same as your initial suggestion #186 thanks again for your help on this!

Closes #185

[bitwalker]

Thanks for contributing!

Ideally, new executable components would specify prebuilt artifacts, which should be produced as part of the release workflow in that repo (see miden-debug for example). Currently, the protocol repo doesn't produce those artifacts (@lima-limon-inc will likely be opening a PR for that soon). In the meantime, we may make components like this that need to be built from source optional, to avoid making midenup initialization time any more painful than it currently is, until all components are providing prebuilt artifacts.

@lima-limon-inc is working on a change to support that, and to address some related issues, via toolchain profiles. I'll probably wait to merge this until those land, which I expect to be soon - that we can make this new component temporarily optional, until we have prebuilt artifacts available for it.

[saimeunt]

@bitwalker Thanks for your comments, this is super helpful to understand the correct process of adding a new component to midenup.

I have addressed your suggested changes by removing the unnecessary aliases key and moving from github repo to crates.io regarding fetching source.
We are looking into generating pre-built artifacts as part of future releases to speed up installs as requested.
Until then, this can wait and ultimately merged after either optional components are supported or we provide artifacts.

[lima-limon-inc]

Currently, the protocol repo doesn't produce those artifacts (@lima-limon-inc will likely be opening a PR for that soon).

Speaking of which, I've added the ProtocolLib's artifact to their CI on this PR 0xMiden/protocol#2859

In the meantime, we may make components like this that need to be built from source optional, to avoid making midenup initialization time any more painful than it currently is, until all components are providing prebuilt artifacts.
(...)
@lima-limon-inc is working on a change to support that, and to address some related issues, via toolchain profiles. I'll probably wait to merge this until those land, which I expect to be soon - that we can make this new component temporarily optional, until we have prebuilt artifacts available for it.

FYI @saimeunt I'll be opening a PR soon implementing this profiles feature soon.

We are looking into generating pre-built artifacts as part of future releases to speed up installs as requested.
Until then, this can wait and ultimately merged after either optional components are supported or we provide artifacts.

If it helps here are a couple of PR where we've implemented artifact upload:

• feat: add action to upload pre-compiled artifacts miden-client#1936
• feat: add action to upload pre-compiled artifacts miden-vm#3029
• feat: into_package() for ProtocolLib and StandardLib + CI Artifact protocol#2859