Deprecate annotations and improve kotlin dsl configuration. Migrate to kotlin

[F43nd1r]

Closes #810

This makes kotlin a first-class citizen for acra. Maybe move documentation to kotlin as well?

Example configuration:

        initAcra {
            reportFormat = StringFormat.JSON
            dialog {
                title = "Dialog Title"
                setResText(R.string.dialog_text)
            }
            httpSender { 
                uri = "https://acra.ch/not-a-real-endpoint/report"
                basicAuthLogin = "test"
                basicAuthPassword = "guest"
            }
        }

[F43nd1r]

This PR has changed scope a bit, now includes migrating the full codebase to kotlin. The aim is to stay 100% compatible with java, but take advantage of kotlin language features where possible.

[mikehardy]

I think as long as you don't use extension functions everywhere (like material-dialogs did https://github.com/afollestad/material-dialogs/issues/1848) it will be compatible yes - we're still java and we do a subclass so I'll test it you publish a pre-release somewhere I can make a gradle dep. We also do all our config via annotations so I might be a good test drive on any config change. Cheers @F43nd1r

[F43nd1r]

I think as long as you don't use extension functions everywhere (like material-dialogs did afollestad/material-dialogs#1848) it will be compatible yes

Technically extension functions can be accessed in java using the class generated for the defining file. It's ugly, but it works. I'm not relying on that though. There are a few extension functions providing convenience in kotlin dsl. All of them just define shortcuts.

We also do all our config via annotations

Config using annotations will be deprecated or maybe even go away completely with this. For now, nothing should have changed for annotations.

we're still java and we do a subclass so I'll test it

I've attached an early build. Alpha release will follow when I've done some testing myself.
acra.zip