Prefix update for .org consistency

[maevelander]

Ramp plugin was approved for .org repo with slug gutenberg-ramp. We had intended it would be ramp-for-gutenberg (inline with the plugin guidelines on project names). Thus we used the prefix ramp_for_gutenberg_ in the plugin. To remove inconsistency, we should:

• [x] Rename files
• [x] Update option stored in r_f_g key
• [x] Update prefix to gutenberg_ramp_
• [x] Update text domain
• [x] Add a wrapper for the old helper function for backwards compatibility
• [x] Update readmes

[pyronaur]

I submitted a PR, a few notes:

• I renamed the classes and files too

• Due to changes to the options key change - if someone is using ramp_for_gutenberg() function currently - they'll have to do two reloads for the settings to catch up.

To avoid two reloads, we could do something like this on VIP Go helper file, but this seems like overkill:

function gutenberg_ramp_migrate() {

    $old_criteria = get_option( 'ramp_for_gutenberg_load_critera' );

    // Fail fast if there is no old criteria
    if ( false === $old_criteria ) {
        return false;
    }

    $new_criteria = get_option( 'gutenberg_ramp_load_critera' );

    // Cancel if there is already new criteria
    if ( ! empty( $new_criteria ) ) {
        return false;
    }

    // --- at this point $new_criteria doesn't exist, and $old_criteria has been defined

    // Update new option
    update_option( 'gutenberg_ramp_load_critera', $old_criteria );

    // Delete the old option
    delete_option( 'ramp_for_gutenberg_load_critera' );
}

// Ready, Set, Migrate:
// This would run before anything else related to Gutenberg Ramp
// For example
gutenberg_ramp_migrate();

^^-- If that snippet is used, we need to make sure it's loaded before anything else related to Gutenberg Ramp. This seems like a good place to do so.

• How will VIP Go MU plugins handle the rename on GitHub?: https://github.com/Automattic/vip-go-mu-plugins