Implement Initial Monorepo

[Lord-Valen]

Description

Since it takes a lot of work to adapt the tools/scripts and match dependencies between projects, I think it may be best to migrate just this project and set up the infrastructure in this PR and migrate the other projects in subsequent PRs. Moving the git history alone has proven to be the easy part (I have done it, but didn't want to go through with the full migration right away). Essentially, we move all files in the repo to /apps/<repo-name>, commit, add it as a remote in this repo, and git merge <repo-name>/<branch> --allow-unrelated-histories. The hard (tedious?) part is to rework the package.json and resolve dependency conflicts.

I took the liberty of trying out turborepo here, since it only adds to the workspace experience. A free and painless addition, it turns out.

What is done here:

• [x] Added workspaces apps/* (for public stuff) and packages/* (for internal stuff)
• [x] Added turborepo tooling
• [x] Simplified tsconfigs
• [x] Used tsup to bundle cjs and esm
• [x] Adapted CI
• [x] Moved InversifyJS to apps/inversify
• [x] Removed publish-please (should probably re-add but want to also consider changesets)
• [x] Added README.md
• [x] Rewrote CONTRIBUTING.md
• [x] Added LICENSE

Related Issue

#1550

Motivation and Context

Monorepos are easier to maintain, as has been discussed in #1550 and on the Inversify Discord server. Turborepo allows for faster CI and developer experience without forcing us into a system other than workspaces. tsup allowed for a simplification of the build and the tsconfig setup (tsup doesn't support amd so I left build:amd intact). I hope this simplification makes things more approachable.

How Has This Been Tested?

• Verified that all tests passed using both turbo and the inversify test script.
• Verified that the coverage scripts worked correctly and emitted the coverage report.
• Verified that the build succeed using both turbo and the inversify build script.

Types of changes

• [ ] Updated docs / Refactor code / Added a tests case (non-breaking change)
• [ ] Bug fix (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 change)

Checklist:

• [x] My code follows the code style of this project.
• [ ] My change requires a change to the documentation.
• [ ] I have updated the documentation accordingly.
• [x] I have read the CONTRIBUTING document.
• [ ] I have added tests to cover my changes.
• [x] All new and existing tests passed.
• [ ] I have updated the changelog.