allow reactor-specific restrictions on code generation in lfc

[housengw]

There are two approaches to distributed executions that I can think of:

1. call lfc on the .lf file in the local machine, then distribute the generated code to each remote machine according to the reactors they host.
2. distribute the .lf file, then call lfc on each remote machine.

After discussing with @Soroosh129 and @lhstrh, we agree that approach (2) would be more robust and modular in the long run because there would be less edge cases outside of lfc to handle. However, currently, calling lfc on a .lf file would generate code for all the reactors in the .lf file.
This implies that the code generation time for approach (2) would be exponentially higher than approach (1).

This problem can be solved if the user can pass a command line argument to lfc indicating the index or name(s) of the reactor and limit code generation to those reactors.

[lhstrh]

I think that passing a (list of) instance names would be best here. It would be straightforward to record this in the StandaloneContext that gets passed on to the code generator. From there on, adaptations of the code generator will be necessary to single out particular federates to produce binaries for.

[housengw]

when rethinking about this topic I wondered if it would make sense to use a config file to specify reactor-specific code generation. Imagine a program with a good number of reactors (say 10), it would be less tedious if the user can specify in a file what to compile or what not to compile instead of using command line arguments. I am imagining the user using a compiler flag (ex. "--config") to pass in the config file.

I was thinking in the context of distributed federated execution where each machine only needs to compile the subset of the reactors in the lf file that need to run on that machine, which I imagine the subset being relatively small compared to the total number of reactors.

[cmnrd]

I think in the long run, we want to have a build tool (like cargo for rust) that takes care of this. So the approach would be, to have a high level configuration and the build tool figures out what needs to be done. Then it calls the compiler on the right files with the appropriate arguments.