We renamed our `master` branch to `main` but our GitHub Actions workflow
still references `master`.

…tion warning)

Resolves #3523

The issue stems from the definition of `Refinery::Pages::Finder` and its sibling classes (`Refinery::Pages::FinderByTitle` and so on). These are all defined beside each other in [`pages/lib/refinery/pages/finder.rb`](https://github.com/refinery/refinerycms/blob/aee49a603860bf7d5fdb1532b9add5f4e7f839f4/pages/lib/refinery/pages/finder.rb) which gets required in [`pages/app/models/refinery/page.rb`](https://github.com/refinery/refinerycms/blob/aee49a603860bf7d5fdb1532b9add5f4e7f839f4/pages/app/models/refinery/page.rb#L6).

When reloading, Zeitwerk reloads the model, which in turn loads the finder again. But because the file is named `finder.rb`, only `Refinery::Pages::Finder` gets unloaded and reloaded again. All other classes stay loaded and would be patched by the reload. But because `Refinery::Pages::Finder` has been reloaded and initialized again, it got a new `object_id`, thus triggering the **`superclass mismatch`** error.

The solution, that fixed the error, was to move all sibling-classes of `Refinery::Pages::Finder` into it, making them children of `Refinery::Pages::Finder`. Because they are only called inside `Refinery::Pages::Finder` itself, this *should* not make problems.

The former was removed in more recent versions of Ruby.

I noticed when running `rails new -m https://www.refinerycms.com/t/edge`
that it was mangling the `Gemfile` when the `sqlite3` line looked like:

```ruby
  gem 'sqlite3', '~> 1.4'
```

Instead of the expected:

```ruby
  gem 'sqlite3'
```

Our `gsub_file` instruction now captures the entire line and inserts it
inside the `group :development, :test do` block.