Added initial specification of addition and subtraction of integers

[smarr]

This addresses part of #20.

This is a very first step in the direction of having a specification for SOM.
For the moment, this is not more than a specification of integers and addition/subtraction.
Doubles are not yet included in the spec.

A readable version is currently here: https://github.com/smarr/SOM/blob/int-add-spec/specification/index.md
It is kept brief to see whether there's any general feedback (perhaps by @ltratt or @krono).

The code examples in the spec are extracted and used to generated the tests that are part of this PR using https://github.com/smarr/GigaGenSOM/
The resulting code is not very human readable, since it's rather long.
The generated tests are supposed cover all relevant combination of values, which is especially important for Truffle-based interpreters, but not only as #20 showed.

Minor maintenance:

• disable PySOM testing (which is distinct from RPySOM)
• and RPySOM is expected to work

[ltratt]

This looks like a good start to me! FWIW on yksom:

$ cargo run --release -- --cp SOM/Smalltalk:SOM/TestSuite/ SOM/specification/executable_specs/AllSpecs.som
          3,440   0%    7.39kB/s    0:00:00 (xfr#1, to-chk=0/4409)   
    Finished release [optimized] target(s) in 0.04s
     Running `target/release/yksom --cp 'SOM/Smalltalk:SOM/TestSuite/' SOM/specification/executable_specs/AllSpecs.som`
Total number of tests:           24
Number of unsupported optionals: 0
Number of successful tests:      24
Number of assertions tested:     30458

which I think is the expected output?

[krono]

Neat!

(i've done number testing for RSqueak a bit differently, but with a similar goal.
Spec testing is good, tho)

[smarr]

@krono is it actually that different?
You got a nice parametrizable testing framework, and I suspect, you won't need to worry about order dependencies for Truffle specializations, but otherwise, it's a set of operations and a possible set of input numbers, if I understand correctly, right?

Think the difference is mainly that I generate the testing code, and haven't shown yet the specs for the other operations, but the goal is to cover them all. I also generate loops that traverse an array/vector with the data in different orders. Is there something more you might be doing?

The original reason for writing the code generator was to be able to produce large programs, and have something to measure cold-code performance. Whether that's going to work, I haven't tried yet, but I thought, such specs might count as "useful" programs worth benchmarking.