Support annotation based suppression of API problems

[HannesWell]

API problems issued by Api-Tools can currently only be suppressed by using the .api_filters file:

• https://github.com/eclipse-pde/eclipse.pde/blob/master/docs/API_Tools.md#filtering-known-problems

This can be cumbersome, especially for projects like SWT where multiple fragments projects for different CPU architectures share the codebase for that OS and generally using a separate file is also some overhead.

Similar to the java.lang.SuppressWarnings annotation, used to suppress Java compiler warnings, Api-Tools should instead/also provide an annotation based way to manage ignoring API problems.
Analogous the annotation could be named @SuppressAPIProblems.
It would be applied to affected classes or class elements and should accept corresponding parameters to specify the kind of suppressed problem as required (and similar to the values one can pass to @SuppressWarnings).

The RetentionPolicy can probably also be SOURCE if it's not necessary to read them for baseline artifacts.

[laeubi]

This will only work for code-problems, but some needs to be suppressed on generic files (e.g. MANIFEST.MF). A possible way would be to allow adding such suppression to other files (e.g. package-info.java)

The RetentionPolicy can probably also be SOURCE if it's not necessary to read them for baseline artifacts.

I would use at least CLASS so we do not require sources to be present (what already is a mess with @since)

[HannesWell]

This will only work for code-problems, but some needs to be suppressed on generic files (e.g. MANIFEST.MF). A possible way would be to allow adding such suppression to other files (e.g. package-info.java)

Shouldn't have problems that require a manifest update some kind of source, like the removal of an element from a class/interface?
In that case the annotation could also be applied to the container of the causes source, i.e. the class/interface.
But of course we could also support something like e.g. package-info.java if no alternative exists.