interpretation and locking of clsrvconf->servers

There are differing interpretations of clsrvconf->servers==null and modification without locking.
Note: most of the locking is done via the realm objects.

Affected code:
1. at the end of clientwr(), clsrvconf->servers is set to null without any locking. This should most likely indicate that this server should no longer be used.
2. within createsubrealmservers() clsrvconf->servers==null is fist used to identify a dynamic-discovery template (together with clsrvconf->dynamiclookupcommand). Later in that function, it is used for error checking.
3. in findserver() and choosesrvconf() it is again used to identify a dynamic-discovery template.
4. in the proposed fix for RADSECPROXY-69 clsrvconf->servers is also direclty accessed.

Possible effects:
1-2: race-condition, interpreted as error during dynamic discovery. This is basically ok. If this happens, the newly created thread actually ended so quickly that it can safely treated as an error. Only the error message might be misleading in that case.
1-3: race-condition with possible segfault, or a differing interpretation of clsrvconf->servers==null, finally leading to a request being rejected, instead of being forwarded to a different server (if available)
1-4: race-condition with segfault
(note in the master branch, only issue 1-3 is present, and doesn't affect dynamic servers)