Fix new errors due to automatic annotation of Class<T> types

Fix new errors due to automatic annotation of Class<T> types

The null analysis now automatically assumes that generic class types
(the "T" in Class<T>) are always @NonNull. See bug 477719.
This clears a bunch of warnings we had due to using Something.class
as parameters. Great!

However, this introduces a new problem. When a generic type parameter
is used both as parameter and as return value, and the client specifies
an annotation on the parameter during a call, the default behaviour is
to assume this annotation on the return type too.

In some cases this assumption is correct:

    List<@NonNull String>.get() returns a @NonNull String

But in some others it is not:

    Map<@NonNull K, @NonNull V>.get() should *NOT* return a @NonNull V.

Now some methods of the form:

    V something(Class<V> type);

also follow this pattern, and the "automatic" @NonNull applied to V
also gets applies to the return value. In some (most?) cases this is
incorrect, and we have to supply external annotations to change the
return value to @Nullable. Just like we did for Map.get().

See bug 483143 for more information.

The return values of the following methods are now annotated as
@Nullable:

Class.getAnnotation()
DsfServicesTracker.getService()
IRemoteConnection.getService()
IRemoteConnectionType.getService()

and related null-checks were added.

Change-Id: I2c60835160a46e88ff293a5fd68774021c2b00a9
Signed-off-by: Alexandre Montplaisir <alexmonthy@efficios.com>
Reviewed-on: https://git.eclipse.org/r/61521
Reviewed-by: Hudson CI
Reviewed-by: Bernd Hufmann <bernd.hufmann@ericsson.com>
Reviewed-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
Tested-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>