Add support for loading and running shared objects to test framework

[davidlattimore]

Most of our tests currently produce executables, sometimes dynamically linked against shared objects. We have a few tests where we just produce a shared object and currently we always disable execution with //#RunEnabled:false. It'd be good to be able to write tests that produce a shared object and then have the test framework dlopen that shared object, find a particular function and call it.

dlopen can be done with the libloading crate, which we already have a dependency on.

Two possible design options. We could change the RunEnabled command, which currently accepts true or false to accept a third option open. If that's set, then when we run it, we do so via dlopen and dlsym. The symbol to load can just be hard-coded. e.g. entry or we could use _start the same as executables use.

Alternatively, we could leave RunEnabled alone and have a command that sets the name of the symbol to load. If that's set, then when we we run, we'd do so via dlopen and dlsym.

I don't have a preference for which we do - but probably don't do both.

If you'd like to work on this, please let us know so that we can assign it to you.

[ostylk]

I'd like to work on it.

Should we expect the function that is called to return an integer to indicate a status code?