Disable Non-Core Theme Should Remove config Table block.block Entries

What are the steps required to reproduce the bug?

Enable a new non-core theme ("custom") and set it as default. Enable and set a different theme (eg. "bartik")
as the default. Disable the "custom" theme. Remove it from the "themes" directory. Clear the
cache and run cron. There remain entries in the "config" table with "name" fields such as..
block.block.custom_content, block.block.custom_footer

What behavior were you expecting?
The "config" table entries named above should have been deleted when the theme "custom" was
disabled.

What happened instead?
The "config" table entries named above remain, forever!

Problems Caused

- "config" table clutter
- no 2nd chance for a better default enabling of theme "custom"

What I mean by better default enabling is that when block_theme_initialize() is called in
block.module, the config entity system will not allow for a rebuild

function block_theme_initialize($theme) {
  // Initialize theme's blocks if none already registered.
  $has_blocks = entity_load_multiple_by_properties('block', array('theme' => $theme));
  if (!$has_blocks) {
    // The default blocks are set into the correct default regions if the new theme has
    // corresponding region names.

Because the table entries already exist, !$has_blocks == FALSE. This is bad because if, as I
just did, you discover that your "custom" theme region names do not correspond to default
themes region names, you have to manually set the blocks to the desireable default regions
every time you re-enable a custom theme. I edited my theme's region names to correspond and
re-enabled my theme but it was too late. I must manually set up the block into regions because
the "config" table never forgets!