Refine the crypto plugin's is_supported() method

This blueprint is to refine the crypto plugins' 'is_supported()' method to make it a true discriminator among multiple plugins. Currently the 'is_supported()' method on plugins is not really utilized within the extension_manager.py module. This blueprint proposes the following changes based on a meeting with Paul K., Douglas M. and John W.:
1) Modify the is_supported() method to take an 'action' enumeration, one of either ENCRYPT_DECRYPT or RANDOM_BYTES. The method would return True if the plugin can support the 'action'.
2) The extension_manager.py's 'encrypt()' method should then look for the first plugin that returns True from the 'is_supported(ENCRYPT_DECRYPT)' call.
3) The companion 'decrypt()' method should *not* search for a plugin this way, but rather ensure that it selects the *same* plugin used to encrypt a given secret (via the plugin fully quality class name stored with the kek_data table).
4) Rename the 'create()' method to 'random_bytes()'...if the plugin supports it, this method should return a random set of bytes of a given length (in bytes)
5) Change from 'bit_length' to 'byte_length' in all API calls.
6) Add a 'Plugin Developer Guide' wiki...saying that authors should implement all methods in the base abstract class, but raising an unsupported operation of the plugin doesn't support a method, and returning properly from the 'is_supported(<action enum>)' method as well.
7) Remove the 'tenant' argument to methods, or pass in the 'keystone_id' instead perhaps.