- I was going through the `sorbet/files.yaml` moving various things to
  `true`, playing around locally, and happened upon some files that it
  was tracking that had been deleted.
- We want to do some automation of new files, but I'm not sure we'd ever
  considered the possibility of code being removed. :-D
- This adds a `--prune-files-list` switch and updates the Tapioca GitHub
  Actions workflow to use it. Any changes to the `sorbet/files.yaml`
  file will be committed as part of the scheduled Tapioca update job.

- Don't skip Git installation tests on generic OS; remove it instead.
- Install Subversion for macOS Subversion tests.

Once every 24h should be sufficient for both of these.

Otherwise this fails.

- Note GitHub Packages specifically in step names
- Use uppercase for Homebrew name/tag (in case it makes a difference)
- Use `--password-stdin` to avoid a warning

This seems a better fit for us (unauthenticated anonymous access) than
GitHub Packages Docker registry was.

Followed steps on:
https://docs.github.com/en/packages/getting-started-with-github-container-registry/migrating-to-github-container-registry-for-docker-images

Let's trial this and see how it goes.

- Avoid caching RubyGems in GitHub Actions `tests.yml` to catch this in
  future.
- Run `brew doctor` in GitHub Actions `tests.yml` after installing
  RubyGems to catch this in future.
- Ignore relevant RubyGems (and fix outdated comments)
- Never auto-`require` RubyGems that aren't vendored.
- Update `bundler/setup.rb`.

This will allow us to verify that we can merge new sorbet/tapioca
updates.

This avoids weirdness like the merged PR commits being pushed to scheduled opened PRs after merging.

It also avoids wasting resources.

- Ensure `spdx.yml` has same fixes as `tapioca.yml`.
- Don't `reset --hard` to ensure that `brew` commands used are those in
  the same branch rather than always from `origin/master`
- Don't check for an existing branch but instead force-push to it if
  there's any updates.
- Provide sample `brew typecheck` command that can be used.

- In all of the PRs that this Action triggered, the `tapioca-update`
  branch was >200 commits behind the latest `master`.
- As per https://github.com/Homebrew/brew/pull/8435#issuecomment-678546024,
  we shouldn't rely on the `Homebrew/actions/setup-homebrew` master
  (the `origin/master` ref) branch being up to date, so resetting to
  `origin/master` was a bad idea.
- A side effect of this is that when we raise PRs to change the Action,
  the PRs that it generates will include local commits. But functionally
  all we care about is the Action that runs on a schedule.

- ensure we reset to `origin/master` so we only have the commit we care
  about in the PR
- ensure we `git add` to include any new files
- don't use `git commit -a` and instead rely only on files added with
  `git add`

- This'll stop needs-response[bot] from moaning at us.

- The github-actions[bot] PRs don't to trigger CI runs, and are hence
  unmergeable without manual intervention.

- Tapioca is a companion gem to Sorbet that generates RBI files for the
  Ruby gems in a project.
- Whenever Dependabot updates a gem, Tapioca has to regenerate that gem's
  RBI files so that Sorbet can accurately assess the state of the typing
  of a codebase.
- We also must regenerate Sorbet's view of
  [things defined at runtime](https://sorbet.org/docs/rbi#the-hidden-definition-rbi

):
  this is what it calls `hidden-definitions`.
- Obviously, this got tedious to do manually. So here's an Action that
  runs every three days and raises a PR if there are any changes.

Co-authored-by: Vidushee Amoli <vidushee.amoli@gmail.com>
Co-authored-by: Issy Long <me@issyl0.co.uk>
Co-authored-by: Jonathan Chang <jchang641@gmail.com>
Co-authored-by: Mike McQuaid <mike@mikemcquaid.com>

Co-authored-by: Seeker <meaningseeking@protonmail.com>

- Add consistent spacing
- Remove `pull_request: []` warning
- remove identical, implicit `name` usage
- use `actions/cache@v1` for compatibility

Co-authored-by: Bo Anderson <mail@boanderson.me>

This ensures they have access to the correct secrets.

Increase consistency between workflows, use more of our actions and
`@main`.

Set up Homebrew should handle both the Git and Ruby setup for us (and
do so faster).

This allows more code reuse.