Add support for source code FMU's

[Martin Sjölund]

There are several issues that should be fixed w.r.t. FMU's:

• translateModelFMU corresponds to the behaviour of buildModel, and should be called buildModelFMU. translateModelFMU should create a source-code FMU.

We should always create a source-code FMU first, and then update the files within it to include the binaries for one target. So something like: buildModelFMU(M, version="2.0", targets={"linux32","linux64"}) actually corresponds to translateModelFMU(M, version="2.0"); fmuBuildBinary("M.fmu", "linux32"); fmuBuildBinary("M.fmu", "linux64"); (and if the target cannot cross-compile for one platform, you can send the FMU to that platform and compile the sources there instead).

When compiling a source-code FMU, two primary options are needed: linking the runtime, or compiling it yourself (necessary for targets that OpenModelica does not support; embedded targets, etc).

We also need to know which C sources are necessary in order to compile a source-code FMU (which is different for ME and CS).

[Martin Sjölund]

Source code FMUs are now supported, platsforms={"x86_64-linux-gnu"}, etc works. We can now cross-compile for linux32/64, darwin32/64, win32/64, and arm-linux-gnueabihf. We also run tests of fmucheck using wine and darling to test most of these targets (darwin32 and arm excepted).

[Dietmar Winkler]

Sorting these closed tickets away from "Future". Since they were closed after the last 1.9.3 release, it's very likely that they should have been part of the 1.9.4 release.

[Martin Sjölund]

Milestone renamed

[Martin Sjölund]

Milestone renamed