Consider using an "opt in" for overriding file fields

This work is based on #2945188: Clean up media tokens and should be applied after. Using media_dev this works as expected. Using 'global' settings renders files with values from the file entity directly, vs using 'override' uses the values from the token:

In the battle of stripping down unnecessary and duplicate values from media token, I'm happy to say that with this in place and selecting 'global' as field source I've managed to get the media token down to this:

[[{"type":"media","fid":"4","view_mode":"full","attributes":{"height":482,"width":354},"values":"global","alignment":"center"}]]

The only reason the last version worked was because of the carefully selection of allowed properties in the token done in #2945188: Clean up media tokens. This version does the actual test whether or not to use overridden field values from token.

And while I remember it. This option is implemented as radios because jQuery.serializeArray() didn't detect or add the value from a simple checkbox when the values from this form is parsed client side.

Rebase. Chasing latest commit in #2945188: Clean up media tokens

Some more discussion/argumentation around the property values: (global|override) in the token schema:

• Elaboration around #6: media_wysiwyg_format_form() is the main source for building media instance settings, and is done so client side using jQuery.serializeArray(). For some reason this function doesn't seem to pick up input values from single checkboxes, at least not in jQuery 1.4 which ships with Drupal 7.
• Using radios is more verbosive and future compatible in the sense that you tell where the field values comes from, instead of just saying "the fields are overridden."
• To explicitly differ from the token 3.0 format we should avoid using fields as property, as this is already used there.
• It could make sense to use the term field_values to say there the field values are selected from, but this might confuse both developers and misc code about this being an actual field. Remember, fields are now flattened alongside other options in the token.

But I'm open to alternatives as I think values still doesn't say enough about what the property does. On the top of my head we could use:

• value_source. Where should the field values come from.
• instance_fields. You get to have 'fields' as part of the property, which better explains whats going on.
• instance_field_values. This fully explains what the property does, but it is very long.

As I wrote the above suggestions, I immediately fell for instance_fields, because in combination with the actual values (global|override) it leaves little doubt about what it does. Not too long either.

• Renamed schema property 'values' to 'instance_fields'
• Added options to token schema and improved token validation. (Guilty of issue context leakage, I know).

Rebased after patch in #2945633: Upgrade and bump version of stored media tokens to 4.0.

As this feature adds an additional property of the media token, it should be added soon-ish before too many runs the token 4.0 upgrade. It doen't really affect the upgrade, but it should be part of what we call 4.0 of media instance tokens.

A review or some feedback of sorts is most welcome. Otherwise I'll just commit this at the end of this week.

Thx!

I omitted the entire checkbox/jquery problem (which I think is independent of jquery version) by using radios instead. And it made sense to do it this way anyway.

Altered description of radio selector description.

Ignore previous patch. it's wrong. Fix coming up.

Patch didn't apply cleanly any more. Rebased.

Now with an actual patch!

This probably needs a follow-up regarding the actual UI and UX. For now this patch solves the overall problem: Use fields from token or from file entity.