refactor: inline use of attr_predicate

[dduugg]

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same change?
• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes? Here's an example.
• Have you successfully run brew style with your changes locally?
• Have you successfully run brew typecheck with your changes locally?
• Have you successfully run brew tests with your changes locally?

---

The follow-up to #19359 which removes remaining use of the Attrable module. This may be less desirable, as it's used more extensively (n = ~50) and it already had correctly compiled sigs.

The defined method for an attr_predicate :foo was @foo == true, but I was able to reduce this to being provably equivalent to just returning @foo in all but two cases (both involving metaprogramming in Formula, which would require a larger refactor to fix). This was possible due to additional refactoring that replaced nil passing with false values instead, but tests seem to indicate that was a valid change.

Using endless defs for these simple methods make this a net removal of >100 LoC, even with the introduction new sigs, so that hopefully atones for the loss of conciseness of attr_predicate. (There is additional upside in not requiring new code readers to learn this brew-specific abstraction, IMO.)

With apologies for the scope creep in this PR, I was also able to promote a few files to typed: strict in this change set. I'm happy to decompose into separate PRs at a reviewer's request.

[dduugg]

Hmm

brew/Library/Homebrew/dev-cmd/audit.rb

Lines 251 to 261 in cdb6a3d

	# For switches, we add `|| nil` so that `nil` will be passed
	# instead of `false` if they aren't set.
	# This way, we can distinguish between "not set" and "set to false".
	audit_online: args.online? || nil,
	audit_strict: args.strict? || nil,
	# No need for `|| nil` for `--[no-]signing`
	# because boolean switches are already `nil` if not passed
	audit_signing: args.signing?,
	audit_new_cask: args.new? || nil,
	audit_token_conflicts: args.token_conflicts? || nil,

seems to indicate the nil/false distinction matters, in which case i'd need to revert a chunk of this, and stick with @foo == true or !!@foo instead of the simpler @foo for the inlined methods. Sadness.

[dduugg]

Found the rationale for this distinction: #12375 (comment)

[MikeMcQuaid]

I went into this skeptical but: yeh, I prefer this, particularly now we have some Sorbet guarantees. Nice work @dduugg!