Freeze formula definition once first instance is created

[Bo98]

This PR implements safety mechanisms to avoid hitting the unsupported behaviour of modifying a formula's definition (e.g. adding a dependency) after the first instance has been created. Note that you will still have the ability to do so if such changes are applied to only that particular instance of the formula (typically involving private API). Only changes to the global definition on the class-level is prevented, as those would have an undefined effect on existing instances.

Each commit can be separated into a separate PR, but the order matters as each commit depends on the previous one.

Details on each one, in reverse order:

• 22ccede - Freeze formula definition once first instance is created
  • What this does is call self.class.freeze at the begininning of initialize.
  • Since we want to prevent modification of SoftwareSpec etc too, I've made it propagate the freeze request down.
  • We already dup the SoftwareSpecs when create the instance, which means the spec stored at instance level will be unfrozen. I've added code to also propagate the dup down too so everything on instance level is unfrozen and cannot propagate back up to the global definition.
  • A part of this involved moving lazily-initialized variables to a self.inherited method, which act's effectively like a class-level constructor.
• 7e825af - test: avoid improper, late usage of formula DSL
  • Fixes multiple tests that abused late formula modifications like Formula["foo"].class.depends_on "bar", which this PR was aiming to prevent being possible
  • This contains some overlap with install glibc/gcc automatically if too old. #13577, but the PRs merged in any order.
• 39a83ee - formula: require instances to use a subclass
  • Because I'm using self.inherited, some variables are no longer initialised on the Formula base class. Calling Formula.new on this base class never really worked anyway since it doesn't make sense so I made it an explicit error when this action is performed.
• df94985 - requirement: require instances to use a subclass
  • Apply the same logic to Requirement so I can share the logic of BuildEnvironment::DSL better.
  • This technically worked without errors before - but it didn't make any sense since the requirement would have no satisfy conidition so it was a no-op requirement.
• fe87f36 - cask_dependent: fix incorrect requirement logic
  • The change requiring Requirement instances to use a subclass revealed a bug: the logic in CaskDependent was incorrect in a few ways (e.g. it displayed "x86_64" for a formula requiring arm64).
• 0a780b9 - requirement: improve name detection of anonymous subclasses
  • There's logic to use the required cask name if the requirement itself doesn't have a name. But this never ever got used because it would prioritise a class.to_s which is typically not human-readable.
  • This name is in brew deps --include-requirements

[BrewTestBot]

Review period will end on 2022-08-26 at 02:12:21 UTC.

[MikeMcQuaid]

Great work here! Would like to see a bunch more comments (particularly explaining why the code is doing what it is doing rather than what it is doing) and there's a brew typecheck failure but otherwise this looks great!

[BrewTestBot]

Review period ended.

[Bo98]

Had to do 88a8def to get brew typecheck working. If you don't want sig to bleed through as DSL then we could probably do it in formula.rbi instead.

[MikeMcQuaid]

Thanks @Bo98!

[carlocab]

This seems to be causing issues for resources defined inside on_os blocks? See Homebrew/homebrew-core#109417.

[Bo98]

I guess we have no test coverage of that? Which is surprising. Will take a look.