Investigate modernizing approach to sbt plugins

[Darkyenus]

(as mentioned on #37)

It it worthwhile to essentialy fake the project types only to insert a few keys? Woudn't it be better to get rid of the whole project system and just supply relevant key settings in Seq[]'s to be added to the build definition, like other projects do?

Also, this plugin has been started a long time ago and the sbt plugin best practices have likely shifted. See if any of the changes are relevant and whether or not they should be implemented.

[ajhager]

I definitely agree about this. I have started rebooting my knowledge about sbt this weekend, to see what the new best practices are. I would love to see your perspective as well.

[Darkyenus]

After reading up on sbt plugin docs, I have modified the sbt-robovm accordingly. The results are here: https://github.com/Darkyenus/sbt-robovm/tree/autoplugin

These are the important changes:

• iOSProject and NativeProject are no more. Instead, there are two sets of settings, iOSRoboVMSettings and nativeRoboVMSettings, which are to be added to the projects using them. This allows very minimal build.sbt-only build files, as seen here (native project).
• RoboVMPlugin is no longer Plugin, instead it is AutoPlugin. This allows adding robovmLicense task globally and:
• autoImport object in RoboVMPlugin so the keys and settings don't have to be imported. They are only aliased here, so when used in traditional .scala build, people don't have to go through autoImport object. I am not sure on this though.

I have also changed the BuildInfo approach a bit, so it allows easier publishing of testing/custom versions with different name (info on that in the README)

Any improvement ideas/thoughts?

[ajhager]

I have been reviewing your changes, and they look great. This definitely simplifies getting setup.