Address existing UnknownNullness lint violations

[fractalwrench]

Goal

The newly added UnknownNullness lint check has identified several sites in bugsnag-android's public API where the nullability is not explicitly defined. We should annotate these as either NonNull, or Nullable, so that Kotlin users can gain the benefit of compile-time safety.

For example, adding the NonNull annotation to the Client constructor would have the following effect:

Client(@NonNull String apiKey) {}

Client client = new Client(null); // java code will fail at runtime
val client = Client(null) // kotlin code will fail at compile time, because an optional String is not allowed

Further reading: https://developer.android.com/kotlin/interop#java_for_kotlin_consumption

Changeset

Due to the number of violations, this PR will serve as an integration branch for other PRs that address the lint violations. This PR also has regenerated the lint_baseline used to suppress warnings, as its line numbers/warnings are out of date due to changes in #389.

WIP

After all the PRs have been integrated into this branch, the lint_baseline check will be run once more to ensure that no UnknownNullness violations were missed.

Additionally, code inspection will be run to ensure there aren't any inconsistencies in the nullability annotations (for example, a NonNull method which can return null). This should also identify some potential bugs around null checks which can be moved out into separate tickets.

[fractalwrench]

Merging in feature branches to address any remaining comments in one place, and check that:

• CI passes
• Every getter/setter pair uses the same annotation, and doesn't mix-n-match, as this generates a separate field + setter

[fractalwrench]

I've now double-checked that each getter/setter is consistent with the annotation used, which should address all remaining feedback.