Remove code from AutoServiceProcessor that read existing META-INF/services files from the CLASS_OUTPUT location and merged new @AutoService services with them.

[copybara-service]

Remove code from AutoServiceProcessor that read existing META-INF/services files from the CLASS_OUTPUT location and merged new @AutoService services with them.

This behavior was untested and it's unclear what situations would actually need this behavior. Internally, nothing was broken by removing this and continuing to include it was causing problems for reasons I won't get into. If it turns out that open-source users were relying on this behavior we can add it back in with some way of turning it off.

RELNOTES=Removed AutoServiceProcessor code that read existing META-INF/services files.

[tbroyer]

This behavior was untested and it's unclear what situations would actually need this behavior.

AFAIK, this was to accommodate somewhat broken "incremental compilation" in some "naïve" tools (Ant probably, but possibly and more importantly Eclipse, maybe other IDEs too; it was also a problem with Maven at some point), that would call javac with only the Java source files that had changed since last compilation (possibly also other sources files that directly depended on the changed sources), so the processor wouldn't see all the @AutoService-annotated in that case and would then produce an incomplete META-INF/services file.

E.g. given A.java and B.java both containing a class annotated with @AutoService(I.class). If you call javac with both files (and whatever contains the I interface) you get an output file containing both A and B. Now modify B, without touching A; some tools will call javac with only the B.java source file, and now the processor will only see B, and the generated file will be missing A. The fix is to call javac with B.java and A.class in this case, or possibly B.java and A.java.

I have no idea if that can still be an issue in practice nowadays, I only use tools that implement incremental compilation correctly.