Make Tap::each respect the API and clear all tap caches before each test.

[reitermarkus]

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

---

Ensure that Tap::each includes CoreTap and CoreCaskTap when using the API. This ensures all caches can be cleared and Tap::reverse_tap_migrations_renames works correctly when these taps are not installed locally.

More general solution than #16680, which added this before one specific test.

[apainintheneck]

It seems like without modifying Tap.each you could do this instead or something similar. I have not tested this at all though.

Suggested change

	Tap.each(&:clear_cache)
	Tap.each(&:clear_cache)
	CoreTap.clear_cache
	CoreCaskTap.clear_cache

[reitermarkus]

Yes, it will work, but it doesn't make sense for CoreTap and CoreCaskTap not to already be included in Tap.each. In fact, they may actually be included, depending on whether the tap directory exists in tests, which is even weirder.

[reitermarkus]

This should actually be done before the ENV is restored above since this depends on HOMEBREW_NO_INSTALL_FROM_API.

[apainintheneck]

I think it might be worth just making the simple change here (#16710 (comment)) and then discuss how we want Tap.each to behave in a separate PR. It looks like this will change user facing behavior and it's a lot to review in one PR since it's used in a bunch of different places.

[MikeMcQuaid]

Needs rebased now but looks good so far!

[MikeMcQuaid]

brew typecheck needs fixed but otherwise looks good to me, nice work!

[apainintheneck]

This helped solve one of the test problems in #16638. Thanks for catching this, @reitermarkus!