"Enum" classes are not implemented correctly

[jpsacha]

Correct use of current "Enum" classes leads to compiler warnings due to incorrect implementation of those "Enum"s. Consider current implementation of class scalafx.geometry.Side:

object Side  extends SFXEnumDelegateCompanion[jfxg.Side, Side] {

  val BOTTOM = new Side(jfxg.Side.BOTTOM)
  val LEFT = new Side(jfxg.Side.LEFT)
  val RIGHT = new Side(jfxg.Side.RIGHT)
  val TOP = new Side(jfxg.Side.TOP)

  protected override def unsortedValues: Array[Side] = Array(TOP, BOTTOM, LEFT, RIGHT)
}

sealed case class Side(override val delegate: jfxg.Side) extends SFXEnumDelegate[jfxg.Side] {
  //...
}

If we match on an object of that class:

    val a: Side = ...

    a match {
      case Side.TOP =>
      case Side.BOTTOM =>
      case Side.RIGHT =>
      case Side.LEFT =>
    }

We will get compilation warning:

Warning:(49, 5) match may not be exhaustive.
It would fail on the following input: Side(_)
    a match {
    ^

This is despite the fact that we matched all possible values.

Correct pattern for implementing an "enum" is to use case objects for values and sealed abstract class like:

object Side extends SFXEnumDelegateCompanion[jfxg.Side, Side] {

  case object BOTTOM extends Side(jfxg.Side.BOTTOM)
  case object LEFT extends Side(jfxg.Side.LEFT)
  case object RIGHT extends Side(jfxg.Side.RIGHT)
  case object TOP extends Side(jfxg.Side.TOP)

  protected override def unsortedValues: Array[Side] = Array(TOP, BOTTOM, LEFT, RIGHT)
}

sealed abstract class Side(override val delegate: jfxg.Side) extends SFXEnumDelegate[jfxg.Side] {
  // ...
}

Now there will be no compilation warnings if we do a full match, and proper warning if we miss a case.

All "enum" in ScalaFX need to be impemented using this pattern.

[jpsacha]

It may be possible to get rid of the need for explicit declaration of unsortedValues using solution similar to one used by Enumeratum.

[Facsimiler]

Can't recall the bug number, but don't forget that Scala constants should be camel case with a leading capital. Maybe we should fix both at the same time.

Incidentally how would we efficiently implement enums that are just named integers in Java? If we use case objects, then we can't extend an AnyVal abstract base class (I think).

Also, regardless of the type stored, this pattern requires an implicit conversion function to convert the case object to its value.

[Facsimiler]

The other issue is #75.

[jpsacha]

The example in the description was copied from the source code that is still using Java naming for constants. Issue #75 needs to fixed too.