Fix a bug in the read lock implementation when there is a lot of contention

While running Workgen benchmark evict-btree-lookaside.py with a higher number of reader/search threads, we hit an assert in __wt_readlock() with following message:

WT_CURSOR.search: __wt_readlock, 274: ticket == l->u.s.current && l->u.s.readers_active > 0

WT_CURSOR.search: __wt_abort, 28: aborting WiredTiger library

Summary:

Read/write lock implementation in WiredTiger has a bug where a call for read lock through _wt_readlock() would result in assert. This only happens when there are a large number of readers and writers threads that are competing for the lock. This root cause is a buggy piece of code in implementation of wt_readlock() that results in variable value to overflow beyond the maximum value. This bug has existed since current R/W lock was implemented through WT-3345.