Moving (some?) panopoly_search variables out of strongarm

panopoly_search strongarm's a bunch of variables:

• facetapi:block_cache:search_api@database_node_index
• facetapi:block_cache:search_api@node_index
• search_active_modules
• search_api_facets_search_ids
• search_cron_limit

Most (if not all?) of those are things that sites or child distributions might want to customize (I'm not sure what the 'facetapi:block_cache:*' ones are about yet).

In particular, 'search_api_facets_search_ids' will be updated dynamically when a search_api query is run for a new facet type, which means a site could become overridden even without an explicit configuration change.

However, here are a bunch of concerns that come to mind:

1. Depending on defaultconfig: Other modules in Panopoly use defaultconfig, but this module doesn't have a dependency on it currently. I don't know how many sites/distro's use panopoly_search without the rest of Panopoly, but I could imagine a world where there's a site that doesn't use defaultconfig, and then the update would break because the new version that required it. This late in Panopoly 1.x's development cycle, that's something I don't want to do! As an alternative, we could add a hook_install() that just sets the variables to their initial value?
2. Distros/sites already overridding these variables via features_override: if we switch away from strongarm, and there are distros or sites already overriding these variables, then those overrides would stop working. This isn't really an issue on existing production sites, because strongarm'd variables (even overridden ones) get written to the database, but it would mess up the variables values when the site or distro is installed (which could happen for new sites for a distro, or for dev/test sites for an individual site). Since this wouldn't break live sites, I think this is less of a worry, but I'd always prefer not to break anything :-)

Another possibility is an override hack that would still use strongarm, but make it so that features doesn't complain when the specific variables are overridden? We did a hack like this on #2276089: Allow configuring file types for "File" widget without overriding the Feature but I don't know how we'd do it exactly here, because we wouldn't necessarily have the "shadow variable" to contain the true value.

Thoughts?