Add specs for Spec filters

[Fryguy]

@asterite Please review.

This adds basic specs for most of the filters as extracted in #8125.

[Fryguy]

I was trying to find a way to parse a heredoc of an example file, but even if I did, I wouldn't know how to tell it to use the alternate FakeRootContext instead of Spec.root_context. This approach here is similar to what's done in the other specs, so I thought it was good enough.

---

This method produces the equivalent of a spec file named f.cr with:

context "context_f_1" do
  it "example_f_1_1" do
    # noop
  end

  it "example_f_1_2" do
    # noop
  end
end

context "context_f_2" do
  it "example_f_2_1" do
    # noop
  end

  it "example_f_2_2" do
    # noop
  end
end

[straight-shoota]

In #5671 I have set up a parallel DSL for declaring spec examples. Maybe this SpecEnvironment could be useful here as well? It needs to be adapted to reflect the recent changes to spec internals. But it should work as well.

[asterite]

Given the massive breakage that this caused, I wonder if we should simply revert this and keep the old, simpler spec. It's also more flexible. But no focus, no rand test and no parallelism in the future. Maybe it's fine. What do you think?

[ysbaddaden]

@asterite don't revert, the benefits (filters, random and parallel runs) clearly trump the breaking change, which is merely to not trust mutable global/shared data.

The breaking change could have been more explicit in the changelog, thought.

[bararchy]

@asterite I took me 3 days to fix everything, please don't revert XD

[Fryguy]

I think the change that caused the real issue was using at_exit to run the specs. Perhaps we can tweak that part, but the rest of these changes have been really useful. I think these features are very beneficial overall.

Total aside, I have a local branch with random specs, as well as seeded-random specs. It's ready to go, just wanted to get these specs + tags in first, so I'm not building PRs on top of PRs.

[Fryguy]

I'm not sure if there's something more I need to do for this PR...the 32 bit tests are failing, but I'm not sure if it's a general issue or something to do with my code here.

[ysbaddaden]

Nothing but a review from someone with spec internals knowledge.

[asterite]

I'll be busy these weeks so at least a review from me well have to wait, sorry.

[straight-shoota]

This looks really good!

[straight-shoota]

In #5671 I have set up a parallel DSL for declaring spec examples. Maybe this SpecEnvironment could be useful here as well? It needs to be adapted to reflect the recent changes to spec internals. But it should work as well.

[Fryguy]

@straight-shoota Thanks for the pointer to #5671 ... I'll see what I can use from there.

[Fryguy]

@straight-shoota I've reviewed #5671 and I think for now I'd like to keep this PR as is and refactor to something like that later.

---

The SpecEnvironment there is a copy of a lot of stuff, and I'd like to avoid the duplication, but the concept it really good. Looking at Spec itself, the big issue with not being able to test is that it uses a lot of class variables which are in turn called directly from the various methods. Detangling that I think is the key. I've started a branch locally where instead of using the Spec module directly with class variables, we instead have a Spec::Environment class (or perhaps part of RootContext itself). We can still keep the top-level Spec DSL methods for convenience, but they defer to an instance of RootContext with its own environment. Then, in specs, we can create a new RootContext, with a separate environment and it won't collide with the singleton environment. cc @asterite

[Fryguy]

Moved the helper methods into a spec_helper.cr similar to #8310 . This will also make it easier to rebase those PRs later.

[RX14]

Needs a rebase.

[Fryguy]

Done.