release: 0.0.6

…s-contributing

chore: add `cargo-semver-checks` install to the CONTRIBUTING.md

Needed when running `cargo flamegraph --root` for #317

…-itest

chore: fallback to cwd if CARGO_MANIFEST_DIR env var is not set

…build it

…iden-in-itests

chore: add `CompilerTestInputType::CargoMiden` and use `cargo-miden` build it

docs: first pass applying Polygon-wide documentation standards

…ponent-0-16

chore: update cargo-component to v0.16.0

* Replace unmaintained actions-rs steps with manual steps
* Rely on rust-toolchain.toml file for installing required toolchain,
  targets and components. This also cleans up Makefile.toml a bit
* Improve the way we handle build caches using Swatinem/rust-cache. See
  below for details.
* Restructure jobs to run lint/formatter checks and tests in parallel,
  but introduce some ordering in those groups to improve cache coherency
  and reuse, and in some cases, to avoid running expensive actions which
  are very likely to fail anyway. The main difference here is that
  amongst the test group, the unit test job is run first, followed by
  the midenc and cargo-miden integration test jobs. Previously only the
  cargo-miden integration tests were split out into a separate job. By
  breaking apart unit and integration tests, we can fail fast when unit
  tests are broken, and avoid running the expensive integration tests
  when they are very likely to fail if the unit tests are broken.
* Update the `book.yml` workflow to publish our new mkdocs-based
  documentation, rather than the old mdbook-based docs. This was causing
  the workflow to fail, it should now start working again.

RE: caching in CI. See https://github.com/Swatinem/rust-cache for
details on how the caching step works, particularly _what_ is cached,
how it is keyed, and _when_ it is cached.

The changes in this commit cache the results of a successful run _only_
when a push to the 'next' branch occurs, i.e. when a PR is merged. Thus,
all PR runs will use the cache associated with the last successful build
of `next` as a base, and build off of that.

Furthermore, there are three different caches:

* The cache shared by non-test jobs in the `ci.yml` workflow
* The cache shared by test jobs in the `ci.yml` workflow
* The cache used by the release job in the `release.yml` workflow

Previous to this commit, each job had its own cache, and the cache would
be updated on every successful build, causing a fair amount of cache
instability, and resulting in very little reuse.

This commit is more conservative about updating the cache, but shares it
more broadly across jobs, and the more conservative baseline means that
the cache is hit more frequently across all PRs.

The choice to not share the cache between non-test and test jobs in the
`ci.yml` workflow is because we want to maximize the number of jobs that
run in parallel, but to reuse the cache, we must ensure that only one
job is responsible for maintaining it. If we maximized cache reuse, we'd
run all jobs in sequence, but this would be slow. Instead, we break up
the workflow into non-test checks, and tests, and pick a baseline job in
both groups to handle maintaining the cache for that group. These groups
can then be run in parallel, and after the job that maintains the cache
is run, all remaining jobs in that group can be run in parallel.

wrap_comments does not interact well with complex Markdown lists, of
which we have multiple. In general it is still an unstable feature and
not totally reliable, so disabling for now

chore: update rust toolchain and rework ci workflows

`dev` profile to fix the #323 compilation issue.
Add a test to build the new project with `dev` profile.

…ndings` feature

doc: add `--release` option to `cargo miden build` command

…-in-new-proj-template

Switch cargo-miden to v0.4.0 of the new project template with `dev` profile to fix the #323 compilation issue

…o-deps-in-bindings

chore: remove `miden-assembly` dependency from `sdk/base-sys` for `bindings` feature

Release v0.0.7