Convert the path property to a field so it can be translated

Initial patch that pulls the code out from the original patches in #1536944: Allow panes to be translated in order to handle conversion of the path property to a field, which can then be translated properly.

Patch updated to include (crappy) support for the title field from #1860484: Add support for Title module field. This needs work, but does the job for my current use case.

Seems none of the previous patches had the update or install hooks for some reason. Patch updated.

@Dave Reid: Given your experience with Pathauto and other path-related modules, do you think this is the correct approach?

Testbot, do your thing.

Looking at the patch, the hook_install() is creating the field and instance, but that only happens initially when the module is first installed. The hook_update_N() is moving the data from the column on 'fieldable_panels_panes' to the new field, but it isn't creating the field and instance!

Also, when users add a new FPP type via the UI, it doesn't appear to be creating the new instance (unless I'm missing it somewhere).

Marking as "Needs work"!

Removing this from the schedule for 1.6.

The target of the link being saved as a property named path has an unintended consequence when #936222: Merge in pathauto_persist module functionality to prevent losing manual aliases with node_save() calls is also applied: fieldable_panels_panes cannot load the value of the path property, as pathauto transforms it to an array and adds its own keys to it.

This is because pathauto expects the path property of an instance to be the path to the instance, as defined in the core path module. However, FPP uses that property to signify the target of the link. Moving this to a field would prevent pathauto (with that patch) from clobbering the field on entity load.

I believe this patch properly sets up and converts the path property to a path field.

Thank you @t0xicCode!!! I spent more time than I care to admit digging through code to figure out why the links were getting messed up after our server upgraded to php 5.6. The patch in #15 took care of our problem. Since I've already invested so much time, I can probably put in a little more to clean up the alignment and whitespace issues.

Here's the patch from #15, with the unnecessary reformatting removed. I also noticed that while the patch referenced moving the path field to the link fold, it didn't actually implement this. My re-roll should take care of that as well.

Thanks @lunazoid. This issue queue fell through the cracks of my email.

Just realized that in the validation function, entity_language was sometimes returning nothing for me. This updated patch will cause it to default to LANGUAGE_NONE.

I'm tempted to mark this as "works as designed" because FPP objects are not really intended to be viewed on their own, they're really just intended to be an equivalent to fieldable blocks with extra Panels gravy..

Are people using FPP as standalone, end-user visible entities? If so, what was the rationale to do so instead of e.g. a content type?

We're using FPP as intended but the incompatibility with pathauto described here #2494733: Incompatibility between Pathauto and Fieldable-Panels-Panes lead us to trying this patch.

I think @t0xicCode makes a very valid point in comment #14 that the FPP title link is not the same thing as the entity path so shouldn't be stored in the path property.

Patch in #20 works well. Existing content was successfully updated by the update hooks.

Needs tests.