Cask: Initialize yet more instance variables

[samford]

• 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?

---

I previously added some instance variables in Cask::DSL to its initialize method (#19806, #19808) but I missed some last time, so we still see warnings like The class Cask::DSL reached 8 shape variations, instance variables accesses will be slower and memory usage increased. It is recommended to define instance variables in a consistent order, for instance by eagerly defining them all in the #initialize method.

This initializes more instance variables in Cask classes to resolve other situations where this warning may occur. I've been testing this for a while and haven't see any warnings with these changes but there's always a chance that there's still more work to be done.

[MikeMcQuaid]

Thanks @samford! In future: probably worth considering bumping these to typed: strict, too, which will enforce this.

[samford]

@MikeMcQuaid I mentioned it internally just now but I have some in-progress work to expand type signatures in Cask::DSL (it's quite a rabbit hole). When I last left it, there were some areas that I couldn't handle without Doug's proposed changes to the Forwardables compiler but there's no PR for that yet. I'll take a look at my local branch again and see if I can create a PR for what I've done so far (it's basically everything else), though we may not be able to bump Cask::DSL to typed: strict until the Forwardables changes are merged.

I made some additional changes to Forwardables in the process (handling additional type signatures), so I'll check with Doug about how we should move that forward when I dig back into this (sometime after I wrap up the UsesOnSystem PR).