Enhance dependency update process with `Cargo.lock` and flexible constraints

[herr-seppia]

Summary

The current dependency declaration strategy in our project enforces strict equality constraints (e.g., =0.1.0 for dusk_core), which leads to compilation failures when updating dependencies.
A more flexible approach is needed to facilitate updates while maintaining dependency security and consistency.

For example, an attempt to update dusk_core from 0.1.0 to 0.1.1 results in build failures across the entire dependency chain. Since all 9 dependent crates currently require an exact version (=0.1.0), a proper upgrade would necessitate releasing new versions for all of them, significantly increasing overhead and slowing down the update process.
This strict approach makes even minor updates cumbersome, requiring coordinated releases across multiple crates to maintain compatibility.

Relevant Context (optional)

Initially, we introduced strict equality constraints to prevent Transitive Dependency Vulnerabilities, aiming to lock down dependency versions and avoid unintended updates that could introduce security risks.
However, due to how Cargo works when a Cargo.lock file is missing, this strategy does not fully prevent such vulnerabilities because transitive dependencies are not explicitly declared in Cargo.toml. Instead, they are resolved dynamically at compile time by selecting the highest compatible version based on Semantic Versioning (SemVer) rules.
This means that even with strict constraints on direct dependencies, underlying libraries may still be updated to newer versions, potentially introducing vulnerabilities or breaking changes without explicit control.

Additionally, while the Cargo.lock file provides strong version control for dependencies within our workspace, third-party binaries using our dependencies may not use it, potentially exposing them to dependency injection vulnerabilities.
However, there is nothing we can do to prevent this issue. To mitigate it, third-party users can always inspect our Cargo.lock to determine the correct versions to use.

Possible Solution (optional)

• Add a Cargo.lock file at the workspace level to manage dependencies effectively (including transitive dependencies).
• Adjust dependency declaration strategy by selecting one of the following:
  • Using minor version constraints (e.g., =0.4) for dusk maintained dependencies (like dusk_core and phoenix) and use patch version constraints for external dependencies.
  • Relaxing version constraints to allow broader compatibility, relying on Cargo.lock to maintain stability and only update when explicitly needed.
• Regularly monitor dependency versions to address potential issues such as crate yanking.