Add inject_primitives: false to macro_spec

[straight-shoota]

This patch adds inject_primitves: false to the semantic specs in spec/compiler/semantic/macro_spec.cr. I picked this specs file at random. Lots of compiler specs don't need primitives injected. Ideally, most of them should always be fully self-contained and not rely on an external prelude.

In the same motion, I transformed percent string literals to heredocs in order to improve readability and clearly associate the arguments following the code sample to the call to assert_type and assert_error.

Two or three examples in this file still require primitives because they use methods like + and ==. I think they can and should be refactored to be self-contained but I tried to avoid semantical changes to the example codes for now.

The performance impact of spec execution is quite significant:
Without this patch, the 107 examples execute in 11.54 seconds
With this patch, they execute in 1.05 seconds.

Other compiler specs can certainly be improved in a similar way.

[Sija]

inject_primitves: false is a great addition, replacing percent literals with heredoc strings though IMO makes the examples way harder to read - before the expected result would be just a line below the call site, now it's at the top, forcing the eyes to jump back-and-forth between the expected result and the call site.

[HertzDevil]

Instead of:

assert_type(<<-CR, inject_primitives: false) { int32 }
  macro foo
    1
  end
  foo
  CR

This is also possible:

assert_type(<<-CR,
  macro foo
    1
  end
  foo
  CR
  inject_primitives: false) { int32 }

But the main benefit of using heredocs is that if those tests fail, the exceptions thrown from them will have more comprehensible error locations than before because there are no leading spaces or indentation in those code literals.

[straight-shoota]

@Sija I disagree. Previously, you would have all components of the method call distributed across lines before and after the sample code. With heredocs, the method call is clean and concise. The code follows afterwards.
There's less interference of different contexts which makes the code overall easier to read, despite the increased visual distance between last expression in the sample code and the block which defines the expected type.
Heredocs are in general a much better tool for such code samples because of the whitespace handling. With the percent string literals spread over multiple lines, there is a weird empty first line and indents in the sample code according to the indent of the call.

[Sija]

@straight-shoota heredocs are fine in general, it's just this eye-ping-pong that bothers me ;)

[jhass]

Let's not fret about style here.

[sdogruyol]

🚀 Thanks @straight-shoota 🙏