ztex: precheck the secondary solutions to avoid hw errors
the ztex bitstreams gives back the latest checked nonce and
its hash7 value and two possible solutions.

every 250ms the latest nonce is checked and compared with hash7
to count hw errors and adapt the MHz value. one change is to
use the solutions even if the latest nonce is not correct. the
original java ztex code also does it this way.

since the second solution is often not correct we have alot
of hw errors. now we always check the second solution before
we submit it to the cgminer main code.

the java code also ignores all hw errors 500ms after a sendHash.
we now do the same. this can possibly yield in a higher MHz rate.
but the chance is so low nobody will ever notice in practice.
Remember best share per pool and return in API pools
Correct API version to match docs
zero (most) API stats
Merge commit 'ccee686' into HEAD

Conflicts:
	driver-ztex.c
Clean up Ztex change
Merge commit '03f626e' into cg_merges_20130120a

Conflicts:
	API-README
	api.c
Merge commit 'abaaf93' into cg_merges_20130120a
Merge commit '4c2f26e' into cg_merges_20130120a

Conflicts:
	miner.c
miner.php optional user/pass login restrictions
miner.php user/pass fix 'usr' is readonly
diffexactone pool diff1 used for share value calculation is ffffffff... not 100000000... :P
api.c pgaenable not re-enabling the device - plus related debug
API zero - zero statistics - all or bestshare - with optional on screen summary

Conflicts:
	miner.c
Best Share readme

Conflicts:
	README
Semi-Cherrypick: API stats - include pool network bytes + in miner.php

Basically just rename Bytes Sent/Recv to Net Bytes Sent/Recv, and include some SSL data in it

Conflicts:
	miner.php
	util.c
miner.php trim trailing zeros on some of the STATS numbers
Merge commit '9300d79' into bfgminer
Merge branch 'kanoi_cherry_20130120a' into bfgminer
Bugfix: Reset pool bytes received when zeroing stats