Allow customization of/decouple docker container

Nobody has claimed this yet.

I set up SyTest for conduit but had to fork SyTest and build my own containers to get it working.
As I wanted a maintenance free system, currently a bot pulls the upstream git commits and applies them which triggers two container builds on dockerhub. Ideally that should not be needed to save public resources.

To allow using SyTest without the need to fork it and change scripts etc. It would be nice if you could pass a couple of `ENV` vars or parameters to the container.

Some ideas for `ENV` vars:

- `SYTEST_SRC` - To allow using a custom fork of SyTest to be downloaded without the need to rebuild the container.
Currently `bootstap.sh` will download the HEAD of master or develop to `/sytest`. The github URL is fixed in bootstrap.sh

- `SYTEST_TEST_SCRIPT` - Pass custom script location (e.g. `dendrite_sytest.sh` / normally found under `/scripts`)
Currently you pass an argument to the container which is checked against available scripts under the scripts dir. That would still work when using SYTEST_SRC but not if you want to use the upstream repo.

- `SYTEST_INCLUDE` - Include custom homeserver definitions
Currently `Homeserver` and `HomeserverFactory` definitions are in `lib/SyTest/Homeserver(Factory)`.
It would be nice if you could pass a dir where additional definitions can be found (e.g by mounting them at `/sytest_extras` and pointing `SYTEST_INCLUDE` to `/sytest_extras`). ATM you can use the Manual homeserver definition but having SyTest spawning the server would allow to get stdout and stderr which is a nice feature for debugging.

If some of this is already support please say so and maybe note that down in the readme.

Start with bootstrap.sh, the container argument handling for scripts under /scripts, and the Homeserver and HomeserverFactory definitions in lib/SyTest. Compare how custom source, test scripts, and homeserver definitions could be supplied without rebuilding the container. Done should include an agreed customization interface and README documentation for its supported options.

Written by the indexing model from the issue text.