#1998582: Auto-generate machine_name for Views Blocks using [viewname]_[displayname] rather than forcing manual entry solved a problem for views that we should really be solving more generically: providing an avenue for the block plugin to make an initial suggestion about what the machine name for an instance of that block plugin should be. i'm happy we got it in, i just think we didn't go far enough. and that we also got some responsibilities slightly mixed up.
this patch fixes both the responsibility mixup and makes it go whole hog: it adds a getMachineNameBase() method to BlockPluginInterface, implements it on BlockBase and ViewsBlock, removes the one-off method from ViewsBlock, guts most of the icky sticky views_form_block_form_alter() implementation, gets BlockFormController to utilize the new getMachineNameBase() method, then keep appending shit to it until it comes back unique in the exact same way the one-off ViewsBlock method used to do it.
it also removes the corresponding views test entirely. this is temporary. since the id-getting method is no longer is solely on ViewsBlock, but now incorporated onto BlockPluginInterface, then the corresponding test should also no longer be a Views test. i haven't written that test yet - at the moment, i just wanted to get this up to see what else breaks.
this is good because it means that block plugins are, once again, divorced from information about their storage. this makes princess happy because there, not all blocks are standalone, which means their uniqueness cannot be accurately determined by the block storage manager. the responsibility for determining uniqueness is instead left in the hands of the form controller, where it belongs.