Replace attributes (e.g. TypeNode#has_attribute?) with annotations

[HertzDevil]

TypeNode#has_attribute? was introduced in 0.6.1; since then, it has only ever supported @[Flags] and @[Packed], and both cases can be checked using annotations instead, which have been present since 0.25.0:

@[Flags]
enum E
  X
end

@[Packed]
@[Extern]
struct A
  @x = 0
end

{% p E.has_attribute?("Flags") %} # => true
{% p !E.annotation(Flags).nil? %} # => true

{% p A.has_attribute?("Packed") %} # => true
{% p !A.annotation(Packed).nil? %} # => true

# everything except `Flags` or `Packed` is unsupported
{% p A.has_attribute?("Extern") %} # => false
{% p !A.annotation(Extern).nil? %} # => true

Since attributes and annotations are supposed to mean the same thing, I think 1.0.0 is a good time we clean up all remaining mentions of "attribute" and replace them with "annotation". This means

• Removing TypeNode#has_attribute?, and the internal Crystal::Type#has_attribute? whose sole purpose is to expose @[Flags] and @[Packed] to the macro interpreter.
• Replacing "attribute" in the docs (e.g. in Enum) with "annotation".
• Optional: adding a TypeNode#has_annotation?(type : TypeNode) : BoolLiteral method which returns exactly !annotation(type).nil?, to make transitioning easier. Same method can be added to Crystal::Annotatable itself as well as annotatable nodes that currently don't have #has_attribute?, i.e. Def and MetaVar.

[straight-shoota]

Sounds good 👍 Thanks for digging into this. I don't expect has_attribute? has seen much use at all (if any).

I would leave #has_annotation? out. If there's a particular use case for this, we can add it later. But typically you would just need #annotation because you don't need negated .nil? if you use it as a condition for example.

{% if E.annotation(Flags) %}
  {% p "true" %}
{% end %}