Fix for runtime test for multilib support

[kkang-wr]

• I have reviewed the Contributor Guidelines.
• I have reviewed the Code of Conduct and agree to abide by it

Test in a docker with:
1
$ cd /path/to/bats-core
$ ./install.sh /usr/ lib64
$ bats tests
$ ./uninstall.sh /usr/ lib64

2
$ ./install.sh /usr/
$ bats tests
$ ./uninstall.sh /usr/

Both results are as same as before:

172 tests, 5 failures, 18 skipped

[martin-schulze-vireso]

I think the test failure already shows the problem: There are many users who will not run install.sh to "install" bats, so it should work for them as well. I also think that we should find a solution that allows uninstall to determine the correct lib path by itself without requiring the user to specify it.

I am unsure how other projects solve this problem but it might be possible to have a configuration file that only stores some variable definitions like bats_libdir and is optional.

[kkang-wr]

I once thought use a configure file to export such kind of env variable. But I find there is a env var BATS_ROOT exported in bin/bats, so I did the same way.
I'll try to use a config file and check it exist. If not, then quit with some prompt info. I am not sure whether it works because it could put the config file in /etc directory in linux. But I am afraid it may not work for Windows.

[martin-schulze-vireso]

The BATS_ROOT is easily determined by the path to the bats binary. However, the libdir is not as easily discovered. Regarding the install on windows: I am not sure if it is even used on this platform. The current install paths don't strike me as windows friendly but I did not try.

[kkang-wr]

@martin-schulze-vireso I involved a config file and set with the libdir. If the config file does not exist or the env variable does not set , it assumes 'lib'. And I do some work on uninstall.sh. Let's check wether it works.