Compiler: emit simpler debug info for code generated by macros

[asterite]

Fixes what's mentioned in this comment

I chose to expand locations that are inside macro expansions to the location where the macro is expanded, for debug info. That means that for this code:

macro foo
  a = 1
  a += 2
  puts a
end

foo

the debug info for all the contents of the expansion of foo will be at the line where foo is invoked (here, filename "foo.cr", line 7, column 1).

A more correct solution to this, which is removed in this PR, is to generate temporary files for each macro expansion, and use that temporary file name in the debug info. The problems with this approach are:

1. It's hard to name these filenames so that previous compilation info (.bc, .o) can be reused. Maybe we can use a hash of the macro content, but maybe doing so will be a bit slow.
2. It fills the cache directory with these temporary files (maybe not that problematic)

I also copy this comment I left in the code:

# We should have expanded locations with VirtualFiles in them to
# the location where they expanded. Debug locations will point
# to the single line where the macro was expanded. This is not
# convenient for debugging macro code, but the other solution
# involves creating temporary files to hold the expanded macro
# code, but that prevents reusing previous compilations. In
# any case, macro code *should* be simple so that it doesn't
# need to be debugged at runtime (because macros work at compile-time.)

We can leave a better solution for this problem, if the need arrives, for later. For now it's better to have faster compile times than to be able to debug code produced by macros.

/cc @ysbaddaden

[asterite]

Oops, I had other commits too. I rebased now.

[ysbaddaden]

AFAIK this only applies to backtraces at runtime, right? It doesn't affect debugging of macros at compile time? If so, then this looks like an okay solution.

[asterite]

@ysbaddaden Yes, that's the case :-)