SSE2 optimized PoW Validation

Significant performance boost is possible with the SSE2 intrinsic implementation from upstream tarsnap.  Block hash PoW validation is a major bottleneck, so this can considerably speed up the client for all users.  Need 3 ACK's before commit.

**Build Instructions**
* Use branch ```exp-0.8.5.1-scryptsse2auto```
* Add ```USE_SSE2=1``` to litecoind make and qmake parameters.

**SSE2 scrypt visible in debug.log | grep "scrypt"**
* MacOS X 32bit and all 64bit is built to always use SSE2.  SSE2 64bit has already been in testing in OMG2 Linux 64bit since mid-September.
* Runtime Detect: Win32 and Linux32 use cpuid feature runtime detection to choose between scrypt-generic and scrypt-sse2 which is set once in a function pointer during init.cpp.
* If ```scrypt:``` is missing from debug.log then you built without USE_SSE2.

**Changelog** since #75 
* Fixed bitcoin-qt.pro to build scrypt-sse2.cpp with -msse2 without hacks.
* Added scrypt-sse2 unit test coverage.
* Squash and cleanup commits. 

**Test Plan**
* Build the ```exp-0.8.5.1-scryptsse2auto``` branch on all target platforms.
* Look at debug.log for lines that begin with ```scrypt:``` to ensure your build includes SSE2 scrypt.
* Test initial block download and -reindex.  See the below instructions for benchmarking, and please report standard 0.8.5.1 and SSE2 reindex time along with hardware and OS.
* Test build without USE_SSE2=1 and on ARM architecture to ensure that still works.  @martinwguy

**Benchmarking Reindex Performance**
Run litecoind or -qt with these parameters to compare reindex performance of the standard client vs SSE2.

```litecoin-qt -reindex -logtimestamps -dbcache=1000 -connect=0.0.0.0```

dbcache=1000 uses an additional 1000MB of RAM for the leveldb cache which can be good for reindex performance but has little benefit for normal operation.  connect=0.0.0.0 prevents it from making any network connection.  You will want to view debug.log shortly after reindex starts as the timeestamp of height=0 might be truncated from the log before it reaches the end of reindexing.

Obsoletes: #75 #71 and #68 .