Add a settings class to adminKit

[mtekk]

Last discussed as part of the true solution to #29, there is a benefit to including version information with the settings in the database. However, it doesn't appear to be appropriate to just include as an entry in the settings array.

Part of #134

Ideally, would result in the following design:

• A single location for items relating to settings, rather than spread across several classes/locations
• A base class that is intended on being extended before use
  • Extend to add default settings specific to the plugin
• Deal with saving and restoring itself from the DB
  • Deal with settings validation
  • Deal with version migration
• Class instance passed into adminKit/plugKit on instantiation
• Embedded version number (no longer a separate "option" in the DB)

Following actions would likely need to happen:

• [x] Move settings validation into this class <- OBE, changed to setting interface and types, which handle their own validation
• [ ] Move much of the breadcrumb_navxt::setup_options functionality into this class
• [ ] Move much of the breadcrumb_navxt::get_settings functionality into this class
• [x] Move breadcrumb_navxt::find_posttypes into this class <- OBE, moved to breadcrumb_navxt::setup_setting_defaults
• [x] Move breadcrumb_navxt::find_taxonomies into this class <- OBE, moved to breadcrumb_navxt::setup_setting_defaults
• [ ] Move default templates from bcn_breadcrumb to settings class
• [x] Move default setting values from bcn_breadcrumb_trail to settings class <- OBE, sort of, not going to actually remove the values for now

[mtekk]

I'm punting this to the "Next Major Release" which would be 6.5.0 or 7.0, not seeing the benefit to this today.

[mtekk]

In the interest of moving things along quicker, there has been a slight change in plans. The bcn_breadcrumb_trail class is going to keep using the opts array. Additionally, for now, we will still save an array to the database instead of an array of setting classes. The admin interface is moving to using the new setting classes (as is the rest of adminKit). The skeleton of this has been created, next up is some serious cleanup and removal of vestigial code.

[mtekk]

This is pretty much down now. Last two steps are to remove the deprecated functions and to move fully away from opts to settings.