`getMonorepoPackage()` includes `.gitignore`d "packages"

The `getMonorepoPackage()` function returns the highest version package within the monorepo, but pays no respect to `.gitignore`d values.

https://github.com/intuit/auto/blob/be952834e3ce52a6a8a7da048bccaf87fef4eeec/plugins/npm/src/index.ts#L156-L192

For example, our monorepo contains these `packages` declared in `lerna.json`:
```json
"version": "22.1.0",
"packages": [
"packages/*",
"examples/**",
"templates/*",
"tasks",
"deprecated/*"
]
```

`lerna@8.1.8` returns the following for `npx lerna ls` (lightly modified to de-name stuff):
```sh
> npx lerna exec pwd
lerna notice cli v8.1.8
lerna info Executing command in 25 packages: "pwd"
(... some dependency cycle warnings ...)
/Users/me/my-org/my-monorepo/tasks
/Users/me/my-org/my-monorepo/deprecated/deprecated-package-1
/Users/me/my-org/my-monorepo/packages/package-1
/Users/me/my-org/my-monorepo/deprecated/deprecated-package-2
/Users/me/my-org/my-monorepo/deprecated/deprecated-package-3
/Users/me/my-org/my-monorepo/deprecated/deprecated-package-4
/Users/me/my-org/my-monorepo/deprecated/deprecated-package-5
/Users/me/my-org/my-monorepo/deprecated/deprecated-package-6
/Users/me/my-org/my-monorepo/deprecated/deprecated-package-7
/Users/me/my-org/my-monorepo/packages/package-2
/Users/me/my-org/my-monorepo/packages/package-3
/Users/me/my-org/my-monorepo/packages/package-4
/Users/me/my-org/my-monorepo/packages/package-5
/Users/me/my-org/my-monorepo/templates/template-package-1
/Users/me/my-org/my-monorepo/packages/package-6
/Users/me/my-org/my-monorepo/packages/package-7
/Users/me/my-org/my-monorepo/packages/package-8
/Users/me/my-org/my-monorepo/examples/package-6/example-custom
/Users/me/my-org/my-monorepo/examples/package-6/example-default
/Users/me/my-org/my-monorepo/templates/template-package-2
/Users/me/my-org/my-monorepo/deprecated/deprecated-package-8
/Users/me/my-org/my-monorepo/examples/package-7/example-custom
/Users/me/my-org/my-monorepo/examples/package-7/example-default
/Users/me/my-org/my-monorepo/templates/template-package-3
/Users/me/my-org/my-monorepo/packages/package-9
lerna success exec Executed command in 25 packages: "pwd"
```

Recently we added `jest@29.7.0` to the `package-7/example-default` and `package-7/example-custom` apps and then released a major. Given we were on `22.1.0`, we expected a release of `23.0.0` but instead received `30.0.0`. We bumped our logs up to veryVerbose and dug through and found 3 references within an invocation of `npx auto shipit` for the monorepo version being resolved at `29.7.0`, `22.1.0`, and `22.1.0`:

`npx auto shipit` output lines 570-1093 (references `v29.7.0`):

```diff
+ℹ info NPM: Got previous version from package.json v29.7.0
ℹ info Getting labels for project: praxis
ℹ info Found labels on project:
[
...
]

Environment Information:

"auto" version: v10.43.0
"git" version: v2.39.2
"node" version: v20.16.0
GHE version: v3.11.7

Project Information:

✔ Repository: my-org/my-monorepo (​https:///my-org/my-monorepo)
✔ Author Name:
✔ Author Email:
+✔ Current Version: v29.7.0
✔ Latest Release: v22.1.0 (​https:///my-org/my-monorepo/releases/tag/v22.1.0​)
```

`npx auto shipit` output lines 570-1093 (references `v22.1.0` 2x):
```diff
+ℹ info NPM: Got previous version from package.json v22.1.0
ℹ info Adding new changes to CHANGELOG.md.
ℹ info Calculating SEMVER bump using:
{
labels: [
...
],
versionLabels: Map(6) {
...
},
options: { onlyPublishWithReleaseLabel: undefined }
}
✔ success Calculated SEMVER bump: major
ℹ info Calculated next version to be: 23.0.0
ℹ info Old changelog exists, prepending changes.
ℹ info Wrote new changelog to filesystem.
+ℹ info NPM: Got previous version from package.json v22.1.0
✔ success Created old version branch: release-22
⚠ warning Everything up-to-date
```

Notably, `/Users/me/my-org/my-monorepo/examples/package-7/example-default/node_modules/jest` does not appear in the `npx lerna ls` output above, so `auto`'s resolution of monorepo packages in this regard differs from lerna's resolution.

---

I do realize and acknowledge that (as I learned yesterday) adding `foo/**` patterns as `packages` is not a recommended pattern. We have now worked through the issue by dropping `'examples/**'` in favor of `'examples/*', 'examples/*/*'`.