Add capability to select custom runtime modules using `lingo`

[lhstrh]

This will allow us to specify as part of the project configuration an implementation for a given runtime module. So far, this will work only for tracing. Initially, we'll just look up the .a file from the filesystem, but we should think about how these should be retrieved/distributed in the future.

[petervdonovan]

Update: We discussed this and decided to implement this feature in lfc because Docker support is already in LFC and we do not wish to duplicate code nor completely implement a new C-target-specific CMake backend at this time. Changes to Lingo will be only at the superficial user interface level so that changes to the LF syntax are not necessary.

This issue is ready and will be picked up when I am done with other UI issues in the VS Code extension.

[petervdonovan]

Initially, we'll just look up the .a file from the filesystem, but we should think about how these should be retrieved/distributed in the future.

I think that it is reasonable to expect users to install these tracing libraries somewhere on their linker search path and then refer to them only by name (for example, telegraf_lf_trace_plugin) in their Lingo.toml. Then the plugin is a dependency like any other, which needs to be installed in some unspecified or loosely specified location on the system but which, once installed, will be freely available to use and reuse without worrying about absolute paths or copying files around. I see this as at least a medium-term solution. I do not see better alternatives anywhere on the horizon.

In the long long term we could think about implementing dependency management ourselves rather than using the standard C library style of dependency management, but as we have seen in our interactions with the ROS ecosystem, it is pretty difficult to set up full-featured, easy-to-use customized build systems that are compatible with legacy tools and libraries.