B 52610 dynamic ports

- All tests auto generate dynamic port numbers to use via the PortFinder class. Each test uses the PortFinder singleton, so all tests automatically have different port numbers, without overlap.

- All configs files were changed so that thetemplate parameters did not conflict with maven properties during resource filtering. In the future, we should remove as many of those maven properties as possible.

- applyConfigs() now copies config files and applies template parameter substitution, just like applyConfigsRuntime() used to. There is no longer any updateConfigs() nor applyConfigsRuntime().

- All (non-bug) tests run on my machine, with one exception. I assumed that all tests pass unless otherwise noted, so I went in a fixed some of the test logic when it conflicted with the change to dynamic ports. For example, where a test said something like 'url = "http://localhost:8888/"', I changed it to something like 'url = "http://localhost:${reposePort}"'. In a few cases, I noticed something that was definitely wrong with the test and fixed that, if I could (for example, trying to start deproxy twice on the same port) .
- Some tests marked as Bug failed. This is expected. I made no changes to those tests except for logic related to dynamic ports.
- The tests marked as flaky *usually* passed, even if they needed some changes. When they did fail, I ran them again until they passed. It usually didn't take more than once or twice.
- The one exception in all this is TranslationSaxonEEFunctionalityTest. There were some errors in the test data for both test methods. I did what I could for the first method, but I don't have the info needed to fix the second.
  - [x] in "when translating json within xml in the request body", the test data was changed to use "<category ... />" instead of "<category ... ></category>".
  - [ ] in "when translating json within xml in the response body", there is the same problem. However, I didn't make the change here. I tried it out, but problems with the "id" field within the json response body meant it didn't match what's in the xsl. I'm not exactly sure the purpose of the test, so I can't fix it myself.
- Additionally, TranslationSaxonEEFunctionalityTest wouldn't run in the IDE unless I set your environment variables (SAXON_HOME in particular) manually. Once the env var was set, it was able to run.