Isolate included macro evaluation context from including type

[makenowjust]

Fixed #9488

Now included macro is evaluated on included module context. It makes intuitive and useful result in many cases. And, extended macro is also evaluated on extended module context.

One example is #9488, and other example is the following:

module Collect
  NAMES = [] of String

  macro included
    {% NAMES << @type.name.stringify %}
  end
end

class Foo
  include Collect
end

class Bar
  NAMES = ["hey"]
  include Collect
end

p Collect::NAMES

The last p prints ["Foo"] currently, however my expected result is ["Foo", "Bar"]. This PR also fix such case.

MEMO: it is breaking change.

[asterite]

Shouldn't this be path_lookup: current_type?

[makenowjust]

No. It will not change anything.

[asterite]

I think should be float64. The type should be looked up in the including type. That's why we should use current_type.

Note that the hook is already executed in the including type, for example if you add a method to it. So type lookup should also be done from the including type.

[makenowjust]

However, the hook name is just included. So, it seems intuitive that included module executes it.

In fact, Ruby's included hook works in such way:

module Foo
  A = :Foo

  def self.included(klass)
    p A
  end
end

class Bar
  A = :Bar
  include Foo
end

# output:
# :Foo

[asterite]

Yes, but in Ruby you get the klass as the including type, we don't do that in Crystal because we don't have runtime define_method and other stuff.

As I said, the current semantic should be revised before we try to change it or fix/brake things.

[makenowjust]

See #5354. I consider included hook is a feature that it appends Foo.included automatically at include Foo if Foo has included macro, so this fix is correct in this view.

[asterite]

I'm not sure #5354 is correct. It's unintuitive that the macro looks up type in the call scope and not the scope where the macro is defined.

All of this to say: we should formalize the semantics that we want here and then implement it. Right now this was all done with guesses and heuristics. This PR might fix something for some, I'm sure it will break code for others and we can't do that right before 1.0.0, specially not without understanding what we really want.

[asterite]

We shouldn't merge this PR until we decide what semantic we want for this. There are conflicting interests.