Fail deployment when configuration for blocked api endpoints is invalid to avoid security issues

[poikilotherm]

The configuration for blocked API endpoint basically allows any value.
In case of typos or misconfiguration (like a /api prefix due to copy+paste from Apache/NGINX rules), the rules are essentially rendered useless.

We must check during deployment if the setting is making any sense to us.

1. Make sure there's no /, or /api or /api/v\d+/ at the beginning of each
2. Make sure the list is actually a list (so no invalid characters like ; or , etc)
3. Ideally check if the referred resource actually exists. (This might be hard to do!)

Also, the whole class of API filtering should be refactored:

1. Extract the matching logic and have unit/integration/API tests
2. Look into using UriInfo instead of or in addition to ResourceInfo to make the code potentially less complex
3. Remove Jetty StringUtil (also add a check in Maven to flag or fail PRs introducing these imports!)
4. Potentially make the class more restrictive in it's choices what are acceptable configuration combinations

In addition: the setup scripts are still applying database options for the blocking configuration. This should be cleaned up.

[donsizemore]

This morning I observed a remote installation whose blocked endpoints included "admin and makeDataCount" so it might be nice to strip quotes from blocked endpoint strings (stop me if this is going overboard).

@poikilotherm Does the installer update warrant a separate issue? Happy to submit a PR there.