Only clear our variation cache pre-3.9.
Only define DONOTCACHEPAGE as true if it is not already defined.
Avoid notices in purchase log list table by checking for the existence of the first name, last name, and email.
Fix minor doc typo.
Avoid strict standards pass by reference error.
Eliminate extra  global in save_forms_to_db() method.
Avoid notices on Purchase Log page.
Whoops
Whoops
Visitor Meta Cleanup Hardening

Visitor meta cleanup determines the list of expired visitor IDs, then for each ID uses AJAX to request that the visitor is deleted.  This fixes several issues.
* Any hooks attached to deleting a visitor while is_admin() is true will now run when a visitor is deleted
* Memory usage is no longer excessive.  Because each visitor is deleted in it's own envelope of HTTP processing slow memory growth is no longer an issue when deleteing hundreds or thousands of users
* If the time alloted for deleting users is reached, or the memory used while deleting users reaches a threshold, the delete user processed is stopped. Prior to the process being stopped a cron task is scheduled to delete the remaining users.  This cron will run a small after a short delay but will not wait for the next hourly delete visitor cron cleanup.  This addresses the issue where more visitor are created in an hour than can be deleted in a single pass of the visitor cleanup routine.
* If an some type of severe error occurs deleting a visitor it does not stop the processing for other users.  The single request to delete the visitor will fail, but other continue becuase they are being processed in a different HTTP context.

To help diagnose visitor cleanup cron issues a non-autolaoad option is saved every time visitor cleanup runs.  The option contains the last run time as a string.
Merge pull request #1089 from JeffPyeBrook/pr-visitor-meta-cleanup-hardening

Visitor Meta Cleanup Hardening
Visitor Authentication Security Hardening

**Insipred by CVE-2014-0166 resolved in WordPress 3.8.2**
Instead of using wp_hash, a pluggable that can be overridden we use hash_hmac with a wll defined WPSC_SALT
Introduced WPSC_SALT an constant that can be defined in our config files, or takes on the value of the WordPress Authentication salt.
If the WordPress authentication salt is not available a unqiue salt is created using the file name, which should be cosntant, and the file path, which should vary from installation.to installation.

**Also...**
Removed a call to ctype, this library may not be available on all servers