Add Scala generation support.

[nbauernfeind]

It would greatly simplify stellar's scala sdk (see Synesso/scala-stellar-sdk#13) to use an interface that more natively integrated with Scala than the Java API.

This change adds full generation support for scala. It was tested by generating source code for stellar-core's XDR classes and compiling them with scalac. More thorough testing is TBD.

This is a portion of my contribution for the Stellar Build Challenge 7.

[Synesso]

Thanks Nate. This is looking good.

After running rspec I attempted to compile the results. There were 2 compilation errors & also the warning about classes overwriting on case-insensitive filesystems (I think we agreed this was not a dealbreaker, but I was under the impression that modern Windows systems are case-sensitive - however this doesn't seem to be the case. We probably should avoid case-insensitive class filename collisions).

$ for d in `ls`; do (echo $d; cd $d && scalac *.scala); done
block_comments.x
const.x
TestArray.scala:20: error: not found: value FOO
  def decode(stream: XdrDataInputStream): TestArray = TestArray((0 until FOO).map(_ => stream.readInt).toArray)
                                                                         ^
one error found
enum.x
nesting.x
MyUnion.scala:59: warning: Class MyXDR.MyUnion$One differs only in case from MyXDR.MyUnion$ONE. Such classes will overwrite one another on case-insensitive filesystems.
  case class One (
             ^
MyUnion.scala:67: warning: Class MyXDR.MyUnion$One$ differs only in case from MyXDR.MyUnion$ONE$. Such classes will overwrite one another on case-insensitive filesystems.
  object One {
         ^
MyUnion.scala:72: warning: Class MyXDR.MyUnion$Two differs only in case from MyXDR.MyUnion$TWO. Such classes will overwrite one another on case-insensitive filesystems.
  case class Two (
             ^
MyUnion.scala:82: warning: Class MyXDR.MyUnion$Two$ differs only in case from MyXDR.MyUnion$TWO$. Such classes will overwrite one another on case-insensitive filesystems.
  object Two {
         ^
four warnings found
optional.x
struct.x
test.x
OptHash1.scala:16: error: value encode is not a member of Option[MyXDR.Hash]
    self.encode(stream)
         ^
OptHash1.scala:20: error: type mismatch;
 found   : MyXDR.Hash
 required: Option[MyXDR.Hash]
  def decode(stream: XdrDataInputStream): OptHash1 = OptHash1(Hash.decode(stream))
                                                                         ^
OptHash2.scala:16: error: value encode is not a member of Option[MyXDR.Hash]
    self.encode(stream)
         ^
OptHash2.scala:20: error: type mismatch;
 found   : MyXDR.Hash
 required: Option[MyXDR.Hash]
  def decode(stream: XdrDataInputStream): OptHash2 = OptHash2(Hash.decode(stream))
                                                                         ^
four errors found
union.x

[nbauernfeind]

@bartekn The ideal testing I have in mind would run binary encoded events through a testing program that would be provided per language. (May not be automated via travis - but would be easily runnable offline.) The idea being that one could convert binary -> decoded message in the new language -> and back to binary. The round-trip at least guarantees encoding/decoding is symmetric. Having a nice suite of prepared messages is convenient for future language integration.

[bartekn]

@nbauernfeind yeah, I think it makes sense. We could create a testing set of XDR definitions (including all standard types) and make sure these are encoded to the same binary form (and the other way: from binary to data) using a different implementations. This shouldn't be hard to do and will provide a good coverage. If you want to work on this, please do it in a separate PR.