Expand ameba's functionality with semantic information

[nobodywasishere]

Currently ameba uses only the stdlib parser in order to provide an AST for the rules to operate over. This is useful, but limits the kinds of things that ameba can be used for. This is an issue to discuss if semantic information to ameba, what that would look like, and what are the downsides / tradeoffs to different approaches. For instance, if we added a top level semantic pass:

• That would require operating at the shard-level instead of individual files (at least for semantic-level rules)
  • Opens up to more semantic compiler errors, but I think the parser rules and top-level semantic rules should operate independently
  • Need to figure out how this would work with linting while typing for the vscode extension, as there may be multiple files open with changes in them, and we'd want ameba to operate on those instead of the ones saved on disk
  • How would the top-level semantic interact with the Excluded in .ameba.yml?
• One of amebas benefits right now is how fast it is, we should profile this to see how worse it is
  • We'd be going from parsing singular files to parsing all files in stdlib/lib/current shard + semantic pass
• What would we be able to do with a top-level semantic that we can't now?
  • Namespace collision detection: https://github.com/crystal-lang/crystal/issues/6194
  • (Maybe) type unsafe equality if both sides of comparison are typed
  • (Maybe) type unsafe hash key types if things are explicitly typed (see crystal-lang/crystal#8893)
  • Typing/{Instance,Class}VarTypeRestriction - currently running into potential issues where an instance var could be typed somewhere, but just not in the current file, leading to a failure
  • Know what calls are to methods or to macros, for better Lint/UnusedVariable and others

[nobodywasishere]

Other rule ideas possible with top level semantic (not saying these should be done, but that they could be):

• Lint/NoReopen - disallow reopening of classes (or maybe monkey-patching stdlib classes/structs/etc)
• Documentation/OverwrittenDocs - warn when adding documentation to a class/module/lib in multiple places which ones will be ignored
• Documentation/UselessShowdocDirective - warn when a :showdoc: directive doesn't work (once those are added)