Split jetpack_file_data based off of autoload needs

On a rather small site I'm administering, the `option_value` field for `jetpack_file_data` option in `wp_options` is 61KB. The problem is that this option has `autoload` set to `yes`, meaning *each and every* pageload ends up transferring 61KB - most of which is wholly unneeded - from the database.

This option contains things like the description for various JetPack modules, the original and supported WP versions for different modules, and even options for settings that are not present in the current installation such as ad management.

No matter what, simply serializing an object containing all this data and dumping it into a single kv pair in the database is ridiculous and screams bad design in the first place, but having it such that this content is loaded for each and every page load is just too much.

May I advise that the serialized contents of this field be pared down to the bare minimum, that fields that are not actually required to be autoloaded are moved to a different kv, and that in general, the size of the serialized content is kept in mind wherever possible. The problem with using PHP's generic serialization is that it is fully-typed by default, field names of objects are serialized too - not just their values (a la protobuff and others).

Start by tracing how the `jetpack_file_data` option is stored and consumed in `wp_options`, and identify which contents are needed during every page load. Measure the autoloaded payload and determine how the remaining module data could be separated. Done means the autoloaded data is reduced without losing required module behavior.

Written by the indexing model from the issue text.