Fix issues with new nullability annotations

[ljacqu]

This issue handles short-term issues that block a release; long-term issues will be handled in #319.

Issues:

• Fix line length issues (check with CodeClimate)
• Ensure that the build works locally again -> IntelliJ picks up its notnull annotation and adds bytecode that rejects null arguments
• Property values are sometimes declared as notnull, sometimes as nullable (e.g. ConfigurationData#setValue is not-null, vs. #getValue is nullable... huh?). See also export values, BeanPropertyType allows null in toExportValue but it is not allowed in ListProperty
  • Not sure what the ideal thing is here, because BaseProperty impl. should never be null, and pretty much for all the use cases I envision for ConfigMe, property values aren't null. Maybe go all in and just declare them not-null everywhere? After all, Property<Optional<T>> is promoted for any cases where we want to skip having values.
• PropertyBuilder#type is null for the inline array implementation. Adapt.

[ljacqu]

It's a core concept of ConfigMe to not return null as property values since we'll fall back on the default value if we don't have any other knowledge. Nevertheless, I'm a little hesitant to flat out deny the possibility of having null as values if someone wants to use ConfigMe in such a way—as such, I've removed some @NotNull annotations from property values, which is not great because that's exactly what you'll get into contact with during normal integrations of ConfigMe.
I'm thinking maybe we could overload the methods cleverly to have @NotNull on another method named the same, and maybe have a marker interface?? It's a little overkill but I don't know how to keep the best of both worlds. I like the marker interface better than a concrete SettingsManager implementation that checks that all values are not null (or that all properties extend BaseProperty) because the marker interface can be used for other property implementations.

[ljacqu]

Need to sleep on this. In the spirit of keeping it simple, maybe we should go all in and disallow null values. I think it's one of the core strengths of ConfigMe: being able to get values without needing to worry about nullness. Otherwise, Optional exists and is supported, as would be other home-brewed value "wrappers"

[ljacqu]

Changed to consider property values not null. I think it works out best like this. Only odd remnant is this method in Property:

boolean isValidValue(@Nullable T value);

^ The base impl. makes sure that the value is not null. If I wrote this code today, I would do the null check (if at all) outside, e.g. in the SettingsManager itself. Might be changed in ConfigMe 2.0 to do that. For now I leave it because BaseProperty extensions might call #isValidValue internally (I know I've done so at least once in other projects)