While working on WT-11126, I discovered a couple performance improvements that stand alone.  That is, these changes would help no matter what route we otherwise take in improving configuration string handling.  Also by separating them out, we make it easier to review the totality of changes we'll end up doing for configuration.

The brief summary is that at the very top of every API entry (as part of the API_CALL macro), we call wt_config_check. When an API is called with a non-NULL configuration string, there can be some substantial checking, especially when the config string is long. For each item in the config string, we do a binary search to find a matching check entry. If there are a long of potential config options, that binary search search can have several string comparisons. We can usually shorten the number of compares by using a jump table.

Secondly, if any of the items needs checking (for example, the value must be an integer between 10 and 20, or it must be one of a specific list of strings), there is a bunch of extra parsing that goes on, as each check is a string like this:

"min=1,max=100000"

or this:

"choices=[\"all\",\"cache_walk\",\"fast\",\"none\",\"clear\",\"tree_walk\"]",

When WT is built, we can reduce these to integer fields or arrays of strings for fast checking.  This avoids the need to parse check strings at the beginning of API calls - currently, depending on the config options selected, we may have to parse (and verify) multiple check strings for a single API call.