inc/class-rewrite.php - Resolve issue #304

While creating rewrite rules, preppend category slug by it's
ancestors slugs only if $taxonomy['category']->rewrite['hierarchical']
is true. Until now, users who set it to false got 404 error code
instead of subcategory pages.
Initial setup of option management class
Fix the issue on missing/exceeding 'www.' in some host/wordpress configurations that falls in a 'Domains, protocols and ports must match' error
Implementation of option validation and default settings via Settings API

* Enhancements:
- If WP_DEBUG is on, a block with the current options will be shown on the settings pages
- Use of selected() and checked() where applicable
- Added error message for when meta description removal fails
- Updated Webmaster tools urls
- Bow out early from displaying the post/taxonomy metabox if the post/taxonomy is not public
- Small function call efficiency improvements
- Added option to add meta keywords to post type archives
- Added error message when user tries to restore to defaults a non-existent blog (multi-site)
- Trim extravars for clean permalink, so the input can be readable (with spaces around comma)
- Moved any output adjustments to the input validation

* Bug fixes:
- Fix bug in delete_sitemaps() - wrong retrieval of needed options
- Failed meta description removal would still change the relevant option as if it had succeeded
- Corrected adding of hidden fb_admins fields to social form
- Not all options where removed on uninstall (still incomplete, see @todo's )

* Consistency:
- Where I came across it anyway, changed inappropriate double quotes to single quotes
- Output escaping of the form generating functions
- Fixed a few spelling errors
- Renamed wpseo/tracking_popup to tracking_popup_done so it's clear what the option means
- Flattened wpseo/theme_check option array for easier validation

= To do =
Deal with version number
Double-check that I've caught each and every option in use
Double-check that the forms send in all options, if one is missed, fall back to $old value
Rewrite the wpseo_defaults() function
Rewrite & move the reset_defaults() function
Double-check the maybe_upgrade() function
Double-check option-import from other plugins
Merge branch 'Admin-page-header-improve' into Fix-settings-issues

(Solved) Conflicts:
	admin/class-admin.php
	admin/pages/dashboard.php
	admin/pages/internal-links.php
	admin/pages/permalinks.php
	admin/pages/rss.php
	admin/pages/social.php
	admin/pages/xml-sitemaps.php
	css/yst_plugin_tools.css
oops.. parse error
Oops... brackets...grr
* Improved form accept-charset property

* Added extra security check for update validation
* Some clean up
Merge branch 'master' of git://github.com/jdevalk/wordpress-seo into Fix-settings-issues

Conflicts:
	admin/class-metabox.php
	wp-seo.php
Merge branch 'master' of git://github.com/jdevalk/wordpress-seo into Fix-settings-issues
Added some checking for is_object() for uses of the variable option name options

Added some 'is not empty array' checking around some foreach()'s
* Added sanitation/improved validation to $_GET and $_POST variables if/when they are used in a manner which could cause security issues

* Moved loading of our text domain forward from wp_loaded to the init action as advised in the codex and registered the translating of default options to be run straight after

* Renamed a number of options within the wpseo_titles option as they ran the risk of being overwritten by post type/taxonomy options which could get the same name
* Added property $variable_option_name_patterns to deal with which these kind of keys which *may* need to be allowed to stay in the options domains, even if the post type/taxonomy it is for, at the time of validation, does not exist yet. Added retain_variable_keys() method for that same purpose.
* Resorted to called enrich_defaults() a lot more often than I would like, to allow for new post types and taxonomies being added during the run

* Solved the problem of adding back our default filters in the update_option() function - even when the update would fail (previously they were only added back if the update succeeded, causing a security hole)
Slight enhancement to the debug info
Properly do Yoast tracking cron job scheduling & unscheduling
Merge branch 'master' into Fix-settings-issues

Conflicts:
	inc/wpseo-functions.php
Added (un-)scheduling of cronjob to activate and deactivate routine
Merge branch 'master' into Fix-settings-issues

Conflicts:
	inc/wpseo-non-ajax-functions.php
Small fixes
Added line of though about blocking files as a @todo
Removed the 'missing argument'- fix so this is a now a separate branch for the unscheduling