If PRs are not raised correctly, CI can be bypassed

[holly-cummins]

#1459 introduced a test failure. (#1463 fixes it.)

How did the failure sneak through CI? It turns out, CI wasn't run on the PR.

Looking at the history of the PR, I see that when I initially raised it, I accepted a default in my tooling or reused a command from my shell history, and raised the PR against main, not development. I then updated the PR to target development, but I suspect by then the CI trigger had been missed. (https://github.com/quarkusio/quarkus-quickstarts/blob/main/.github/workflows/build-pr-development.yml only triggers for development and numbered branches.)

This seems like it's quite likely to happen, just because main is so ubiquitous (and it's the default branch). I can see three possible fixes:

• Change it so that the branch people should be raising PRs against is the default branch. This makes the branch layout less surprising, and seems like it could solve a number of usability problems, but there's a reason for the current branch layout, so we'd need to work through implications.
• Do some sort of extra workflow for PRs against main which immediately fails the checks and says that the PR will need to be re-created against development to trigger CI. This seems like a bit of a workaround, and means every user error leaves a bit of a trail of noise.
• Change the workflow to also trigger on main but then have guards in the jobs themselves to either short-circuit + fail for main or run for development. This reduces the noise of re-created PRs, but means the workflow file is more complicated.