add interfacesOf method to ClassIntrospector, and some cleanup (#2004)

I had originally thought we allowed cycles in the class hierarchy when it comes to interfaces, but it doesn't look like we do, so we can still have a well defined ordering here (which was the only reason I left this off prior).

Also removed the section about adding macro applications to existing declarations. You should be able to just directly invoke the macros inside your macro instead.

Author: jakemac53

working/macros/api/builders.dart

@@ -70,6 +70,9 @@ abstract class ClassIntrospector {
 
   /// All of the classes that are mixed in with `with` clauses.
   Future<List<ClassDeclaration>> mixinsOf(ClassDeclaration clazz);
+
+  /// All of the classes that are implemented with an `implements` clause.
+  Future<List<ClassDeclaration>> interfacesOf(ClassDeclaration clazz);
 }
 
 /// The api used by [Macro]s to reflect on the currently available

working/macros/api/introspection.dart

@@ -58,7 +58,7 @@ abstract class ClassDeclaration implements TypeDeclaration {
   TypeAnnotation? get superclass;
 
   /// All the `implements` type annotations.
-  Iterable<TypeAnnotation> get implements;
+  Iterable<TypeAnnotation> get interfaces;
 
   /// All the `with` type annotations.
   Iterable<TypeAnnotation> get mixins;

working/macros/feature-specification.md

@@ -649,14 +649,6 @@ If a macro application is added which runs in the same phase as the current
 one, then it is immediately expanded after execution of the current macro,
 following the normal ordering rules.
 
-#### Adding macro applications to existing declarations
-
-Macro applications can be added to existing declarations using the builder
-classes. Macros added in this way are always prepended to the list of existing
-macros on the declaration (which makes them run *last*).
-
-**TODO**: Update the builder APIs to allow this.
-
 #### Ordering violations
 
 Both of these mechanisms allow for normal macro ordering to be circumvented.