chore: move rust-vmm deps to workspace dependencies

[hanbings]

Summary of the PR

This PR moves rust-vmm related dependencies to workspace dependencies, and alphabetically reorders some of the crate declarations.

Closes #906

Requirements

Before submitting your PR, please make sure you addressed the following
requirements:

• All commits in this PR have Signed-Off-By trailers (with
  git commit -s), and the commit message has max 60 characters for the
  summary and max 75 characters for each description line.
• All added/changed functionality has a corresponding unit/integration
  test.
• All added/changed public-facing functionality has entries in the "Upcoming
  Release" section of CHANGELOG.md (if no such section exists, please create one).
• Any newly added unsafe code is properly documented.

[stefano-garzarella]

We like to have all the information in the git history and usually PR description will not be part of that, so please avoid commit with empty description, and especially add the reason why we are doing that.

For example in this case one of the reason is to have a single place for the entire workspace where we can handle versions of rust-vmm dependencies.

[stefano-garzarella]

Should we cover also crates in staging/ ?

[hanbings]

We like to have all the information in the git history and usually PR description will not be part of that, so please avoid commit with empty description, and especially add the reason why we are doing that.

For example in this case one of the reason is to have a single place for the entire workspace where we can handle versions of rust-vmm dependencies.

That makes sense. Should I use rebase to update the commit message?

[stefano-garzarella]

We like to have all the information in the git history and usually PR description will not be part of that, so please avoid commit with empty description, and especially add the reason why we are doing that.
For example in this case one of the reason is to have a single place for the entire workspace where we can handle versions of rust-vmm dependencies.

That makes sense. Should I use rebase to update the commit message?

Yes, rebase and force push. Our policy is to avoid any fixup in a PR (e.g. no new commits to fix code added by commits in the same PR), so it's perfectly fine to rebase the PR, update commits (code or description/title) and force push.

[hanbings]

We like to have all the information in the git history and usually PR description will not be part of that, so please avoid commit with empty description, and especially add the reason why we are doing that.
For example in this case one of the reason is to have a single place for the entire workspace where we can handle versions of rust-vmm dependencies.

That makes sense. Should I use rebase to update the commit message?

Yes, rebase and force push. Our policy is to avoid any fixup in a PR (e.g. no new commits to fix code added by commits in the same PR), so it's perfectly fine to rebase the PR, update commits (code or description/title) and force push.

Thank you for the review. I have made the changes in the latest commit.

[RuoqingHe]

Code-wise looking good, it would be better if you could put the "sorting and formatting" changes into a separate commit, and use taplo to format it

[hanbings]

Code-wise looking good, it would be better if you could put the "sorting and formatting" changes into a separate commit, and use taplo to format it

Thank you for the review! I'll address the sorting/formatting changes with taplo in a separate follow-up PR.

[hanbings]

Should we cover also crates in staging/ ?

I've added workspace dependencies in staging/Cargo.toml as well since it has its own separate workspace. It feels a bit redundant to me, but consolidating staging/ into the root workspace would require CI changes too — not sure what the preferred approach is here.