Compile Statement: Parameterize and Split into Reusable Steps

Structuring into different objects:
- CompilerDriver: contains methods that parameterize the interpreter for compilation.
- CodeCollector: contains code collection methods and data that are currently in the interpreter.
    - This collides with the idea to see the generated statements as the function's return value.

Structuring into different methods:
- Functions that direct the compilation for each (type of) main function (for example:
  "compile_dynamic", "compile_init", ...)
    - Find the main functions in the simulation object.
    - Create the empty compiled function, create additional input values if necessary (init_* functions).
    - Call the main function (init_* functions).
    - ???

Parameters for customization:
- Base class of generated Python class.
- Which methods are the main methods
- Signatures of the main methods
- Which roles are legal for assignment

General ideas:
- Convert compile statement into compile function. The function arguments would provide the mini language to specify
  options.
    - Compile function could be written in Siml, and call several built in compilation functions. This would make
      cusomization of the compilation algorithm quite easy for advanced users. They could write their own compilation
      functions.
- Perform data creation step through implementation of data statement
See blueprint for improved data statement:
https://blueprints.launchpad.net/freeode/+spec/data-statement

- Automatic calling of main functions in child objects. No longer writing "system.dynamic()" everywhere.

Data:
The flattened methods should have a structure that already reflects the compiled code:
- code
- input variables
- output variables
- intermediate variables
- state (parameters)