fix: remove packages instead use compact-tools

[0xisk]

Types of changes

What types of changes does your code introduce to OpenZeppelin Midnight Contracts?
Put an x in the boxes that apply

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update (if none of the other choices apply)

1. Remove packages and use compact-tools as a submodule (until it is published then we can use the npm version"
2. Rename package name from @openzeppelin-compact/contracts to @openzeppelin/compact-contracts

Blocked by: https://github.com/OpenZeppelin/compact-tools/pull/5

PR Checklist

• I have read the Contributing Guide
• I have added tests that prove my fix is effective or that my feature works
• I have added documentation of new methods and any new behavior or changes to existing behavior
• CI Workflows Are Passing

Further comments

If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc...

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/compact-tools

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[andrew-fleming]

Good initiative on this @0xisk! I talked offline with @emnul about this and I don't think it's a good idea to have a private repo as a submodule because outside contributors won't be able to clone it. I think it'd be better to duplicate the packages in both repos (which is obnoxious, I know) and instead set up compact-tools to be public and release it properly as a package. IMO that's the ideal scenario. Thoughts?

[0xisk]

Good initiative on this @0xisk! I talked offline with @emnul about this and I don't think it's a good idea to have a private repo as a submodule because outside contributors won't be able to clone it. I think it'd be better to duplicate the packages in both repos (which is obnoxious, I know) and instead set up compact-tools to be public and release it properly as a package. IMO that's the ideal scenario. Thoughts?

Thanks @andrew-fleming Yes that was the intention to wait on this draft PR on either compact-tools got opensourced, and therefore submodule won't be an issue, or even much better to just release it as a package and just use it here. Sorry that this was not clear in the PR description.