Feature request: packages as git submodules

Here is a suggestion: instead of organizing the `packages` directory as:
```
Macaulay2/packages/
...
├── Matroids.m2
├── Matroids
│   └── SmallMatroids.txt
...
```
let's allow having packages contained in another git repository and allow such an organization:
```
Macaulay2/packages/
...
├── Matroids
│   ├── Matroids.m2
│   └── SmallMatroids.txt
...
```
This wouldn't need to happen for every package at once, but all new packages, and optional for updated packages.

This has many advantages:
- developers (e.g. @giovannistagliano) can continuously update their packages
- users can get access to updated versions of a package immediately (e.g. `pullPackage`)
- users can get access to new packages before a release (e.g. `clonePackage`)
- github actions can run the checks of the individual package on each commit quickly
- github actions can generate examples and documentation and upload it on Github Pages
- before each release, the developers open a pull request to update the submodule hash, at which point all packages are checked together in order to guarantee interoperability
- this method guarantees that old packages stay operational, because we still run all checks on all packages.
- it would also reduce messiness in the packages directory.

Possible extensions:
- we can potentially implement `pushPackage`, which would automate updating a package.
- allow packages names like `Numerical/SchubertCalculus.m2`, so multiple packages can be grouped together under the `Numerical` umbrella and a single repository can contain all of them. Updating those packages at the same time would be simpler this way.
- if Macaulay2 can be made to understand git, then `PackageImports` and `PackageExports` can take an argument like `"LocalRings" => "mahrud/LocalRings.m2 @ [commit hash]"`, which means depend at least on that commit or better.

This is basically universal in all other scripting programming languages with support for packages or modules. We can learn a lot from systems like `brew`, `pypi`, `npm`, [GAP-packages](https://gap-packages.github.io/), JuliaHub, etc.

Start by examining the packages directory and the existing package workflows, including pullPackage and clonePackage, to determine where repository layout and package retrieval are handled. Review the proposed Git submodule organization and GitHub Actions checks, then define the integration and validation work needed for packages to remain interoperable before considering the listed extensions.

Written by the indexing model from the issue text.