Introduce method to introduce new roles and caps independently of db upgrades.

[peterwilsoncc]

Presently adding new roles and caps is avoided to guarantee backward compatibility with sites that don't update the database schema. This has resulted in:

• a bunch of capabilities being used for purposes other than their original purpose
• abuse of meta caps of faux primitives
• filters added to the user_has_cap to introduce faux capabilities (three and counting)

It's a little confusing and these hard coded capabilities make it more complex for sites with custom roles to manage granular capabilities.

Additionally, it has lead to problems in which custom roles that should be given the capability are not. For example a custom role with page editing permissions but no post editing permissions should probably be allowed to add shared blocks.

For the majority of sites which run database upgrade routines, it would be helpful to upgrade the roles and capabilities in the database.

For sites which do not, faux capabilities can be added to the user_has_cap filter in a single function, based on the database version.

For sites with hard coded arrays, the presence of the new capability can be detected and added as a faux capability if it is not.

As an initial construct, a faux capabilities function can be added:

<?php
function wp_update_capabilities( $user_caps ) {
  if ( /* database version < block editors */ ) {
    // Add caps matching user's `*_posts` cap
  }

  if ( /* database version < site health upgrade */ ) {
    // Add caps for users wiht `install_plugins` 
  }

  // etc
  return $user_caps;
}
add_filter( 'user_has_cap', 'wp_update_capabilities' );

Additional design decisions to be made:

• how to use the same function for db updates
• to filter or not to filter faux capabilities
• handling the hard coded arrays