Experimental blocks: gate the block availability behind WP and Gutenberg checks

This is a follow-up to #14104:

> have experimental blocks enabled if you use the constant AND the latest version of WP AND the latest version of Gutenberg. This way we wouldn't have to take any extra precautions when working on those blocks?
-- https://github.com/Automattic/jetpack/pull/14104#issuecomment-567560417

> in thinking about this as a set of blocks expecting the latest version of WP and/or the Gutenberg plugin, should we just call a spade and a spade and check for that?
>
> Ensure the latest version of Gutenberg is installed (as a MVP we can hardcode the version and document that it should be bumped as new code is merged) before loading the experimental set? Since the beta package would have the same requirement, do we need to do that?
-- https://github.com/Automattic/jetpack/pull/14104#issuecomment-567283280

This is not a blocker, but would be a nice way to allow us to work on those blocks without having to worry about breaking things for the few who would try to use the blocks in the wrong environment.

If we were to implement this, I am not sure what would be the best way to ensure that one uses the latest version of WordPress and Gutenberg? Should we rely on the API offered by Core?
https://codex.wordpress.org/WordPress.org_API#Version_Check
https://api.wordpress.org/stats/plugin/1.0/gutenberg

Or should we somehow check if the plugin is installed, and check if an update is available for the plugin?

Start by reviewing follow-up #14104 and its linked pull-request discussion, then compare the WordPress.org version-check API with the Gutenberg plugin stats API cited here. Define how the WordPress and Gutenberg version requirements gate experimental blocks, and identify the block-loading entry point and relevant test coverage; no file or test is named in this issue.

Written by the indexing model from the issue text.