Changes

• Warn developers who aren't using a global afterEach function instead of throwing errors.
• Minor formatting/style changes (in related files only; optional)

Why?

I gave some reasons for why I think this direction of change is desirable in #297 -- specifically here and here. But here's a brief set of reasons for why I think this is the way to go:

1. Developer Experience. Throwing errors at developers who intentionally don't use globals is a really painful DX. Yes, there are workarounds, but any workaround for this problem will admittedly be clunky (and therefore another bad DX).
2. Fragility. The current implementation of the afterEach absence check is very brittle because it only considers Vitest. If we're thinking about the longterm strength of this project, it needs to be able to consider all possible test runners. Only considering one test runner is insufficient, and bloating the if/else checks for every new test runner that gets released will eventually become unmaintainable. Moreover, since it's an internal implementation detail, Vitest can change the ENV variable that they use at any moment (again, making the existing check brittle).
3. Convention: Although Vitest shares many similarities with Jest, it also has some intentional differences. For instance, Vitest intentionally refuses to use globals by default. To create a scenario in VTL that requires Vitest users to use globals (by default) goes against the natural flow of Vitest, and it may disrupt several Vitest users in the process.
4. Documentation: Both Vitest and VTL already document the fact that you must setup afterEach(cleanup) manually if globals are not available for your test runner. The point of the documentation is to catch these exact pitfalls. If the people migrating from Jest to Vitest aren't using the Migration Guide, and if the people using VTL aren't reading the VTL docs, then there isn't really much that the maintainers can accomplish for their users. The docs are very accessible. (I used them to handle my cleanup errors.) But the developer still has to reach for them. And maintainers can only go so far without harming other developers' experiences (e.g., throwing errors when globals aren't available) or making the logs/JSDocs overwhelming. Throwing errors harms DX while negating the point of the docs; so I feel it's best to avoid this.