Recognize any "standard" JVM-style main object in the sbt plugin.

In addition to recognizing objects extending `js.JSApp`, the sbt
plugin now recognizes "standard" main methods as well, i.e.,
objects with a method of the form

    def main(args: Array[String]): Unit = ...

If such an object is used as main class, its main method is called
using the new `ModuleInitializer.mainMethodWithArgs`.

This has the nice benefit that we can finally write a
cross-platform main object.

We "softly" deprecate `js.JSApp`: its documentation says not to
use anymore, but it does not cause a deprecation warning yet.

For backward compatibility, objects extending `js.JSApp` are
still recognized, and their `main(): Unit` method will be called.

There are some subtle scenarios regarding backward compatibility:

* If an object *both* extends `js.JSApp` and has a standard main
  method, the `main()` method of `js.JSApp` is preferred, for
  backward compatibility.
* If an object has a `main(): Unit` method but does not extend
  `js.JSApp`, it will not be *discovered*. In that case, we assume
  the old style and call `main()`. This can happen if the user
  explicitly sets the `mainClass` setting.
* If an object has *both* a `main(): Unit` method and a
  `main(args: Array[String]): Unit` method, it *will* now be
  discovered, and the new style will be assumed. This can
  potentially break compatibility, as now the standard main will
  be called. This only happens in case the user has explicitly set
  `mainClass`. Moreover, it is only problematic if `main()` does
  not behave the same as `main(Array())`, in which case the
  codebase is arguably in a bad shape to begin with.
* The very fact of recognizing *more* objects as potential main
  objects means that the sbt build can break because it cannot
  automatically choose between several discovered objects. This
  will however fail to link with a nice error message, so it is
  not too bad.

Here are some examples.

* Old-style only, `main()` is selected

    object OldStyleOnly extends js.JSApp {
      def main(): Unit = ...
    }

* New-style only, `main(Array[String])` is selected

    object NewStyleOnly {
      def main(args: Array[String]): Unit = ...
    }

* Old and new style combined, `main()` is selected

    object OldAndNewStyle extends js.JSApp {
      def main(): Unit = ...
      def main(args: Array[String]): Unit = ...
    }

* `def main(): Unit` without `js.JSApp` only, `main()` is selected

    object OldStyleNonJSApp {
      def main(): Unit = ...
    }

* Both styles of methods without `js.JSApp`, `main(Array[String])`
  is selected (potentially silently breaking)

    object OldAndNewStyleNonJSApp {
      def main(): Unit = ...
      def main(args: Array[String]): Unit = ...
    }

* Both styles exist in two different objects, sbt reports an
  ambiguity and demands that `mainClass` be set explicitly

    object OldStyle extends js.JSApp {
      def main(): Unit = ...
    }
    object NewStyle {
      def main(args: Array[String]): Unit = ...
    }

sbt-plugin-test/withDOM/src/main/scala/sbttest/withDOM/TestApp.scala

@@ -1,10 +1,8 @@
 package sbttest.withDOM
 
-import scala.scalajs.js
+object TestApp {
 
-object TestApp extends js.JSApp {
-
-  def main(): Unit = {
+  def main(args: Array[String]): Unit = {
     Lib.appendDocument("Hello World")
     Lib.appendDocument("Still Here!")