Modified locking mechanism to enable higher streaming performance to DRAM.

Previously, a cache hit to DRAM would lock an entire page, which would serialize
subsequent accesses to the same page. The goal of this patch is to allow accesses
to different physical addresses within the same page to go to DRAMSim in parallel,
allowing for higher throughput. It adds the pending_flash_addr map to track
the accesses at a finer granularity and only locks the entire page on a cache miss.
Updated contention_is_locked() to use pending_flash_addr
Merge branch 'dev' into lockfix
Moved wait set out of Pending

Previously, whenever a VICTIM_READ to DRAM or a LINE_READ to flash occured
that could result in HybridSim waiting for multiple accesses to complete
before proceeding, HybridSim would create a new unordered_map<uint64_t>,
which would be made available via a pointer called wait in the Pending
set. As the accesses completed, the addresses would be removed from the
wait set. When the wait set was empty, that indicated to HybridSim that
the VICTIM_READ or LINE_READ operation was finished.

In preparation for changing the way the dram_pending and flash_pending
maps are addressed, the wait set pointer was removed from Pending
and two new unordered_map<uint64_t, unordered_set<uint64_t>> were
created in HybridSystem: dram_pending_wait and flash_pending_wait. The
dram_pending_wait map is addressed by a cache page address (just like the
dram_pending is in this commit, although that will change soon). The
flash_pending_wait map is addressed by a page address. Overall,
the functionality is exactly the same as how the wait set worked
previously. The only difference is in how the wait set is stored.
Change CacheRead operation to use data_addr for dram_pending.

Previously, the CACHE_READ operation used the cache page address to track
reads to DRAM. This meant that only one read per page could go out at
a time. Since the fastmem microbenchmark demonstrated that this caused
a major bottleneck in streaming reads (HybridSim achieving ~3.35 GB/s
while DRAMSim was capable of 8.35 GB/s), we want to be able to send
multiple DRAM reads out to DRAMSim concurrently. We accomplish this
by changing the CACHE_READ operation to use the data_addr (the actual
64-byte granularity address that will be sent to DRAMSim to get the data
requested by the external access) in the dram_pending table.

However, since VICTIM_READ still uses the page address to track a large
number of accesses (one for each 64-byte location within a flash page),
this meant that DRAMReadCallback needs to know which address to use (the
data_addr or the cache page address). To determine this, we simply have
it look in the dram_pending_wait map and see if an entry for the current
page exists. If so, then it must be a VICTIM_READ and we use the cache
page address. Otherwise, it must be a CACHE_READ and we use the data_addr.

These changes also depend on the previous commits that implemented locking
at a finer grained level and moved the wait set to dram_pending_wait.

This commit also contains a minor fix in which debug output was not
properly guarded by DEBUG_CACHE.

Also added a new trace file (traces/no_delay_test.txt) to test accessing
multiple locations within a page concurrently.
Transformed cache line lock to be a counting semaphore

Since we now support multiple concurrent accesses to cache lines,
a pattern like this could break things...

contention_cache_line_lock(cache_page);
contention_cache_line_lock(cache_page);
contention_cache_line_unlock(cache_page);
contention_cache_line_unlock(cache_page);

The first unlock() would unlock the line rather than the second as
desired.

This change adds lock_count to the cache_line class and uses it to track
the number of outstanding locks. Now, contention_cache_line_unlock()
doesn't unlock the line unless the lock_count is 0.