Quality-of-life improvements for renamed files

If you do a lot of refactoring, and you notice that your life gets a little bit easier after upgrading to 2013.2 but you can't quite put your finger on why, it just might be one of these changes:

	#601710 (Bug #59275) **
	    Files that have been moved and are open for edit at an older
	    revision may now be scheduled for a filename resolve by syncing
	    to the move/delete revision.  Accepting the new filename will
	    move the open file, similar to 'p4 move -f', allowing the edit
	    to be submitted under the new filename.

About three years ago I wrote a blog post (https://web.archive.org/web/20150402081653/http://www.perforce.com/blog/100601/p4-move-f-what-its) explaining how you could use "p4 move -f" to take a file that had been moved while you were editing it, and move your workspace edit to make it line up with the new depot path.  This change takes that process and makes it automatic.  
When you do a "p4 sync" of an open file that has changed underneath you, we schedule a resolve between your workspace file and the depot revision that you synced to.  With this change, if that depot revision is a "move/delete" (as it will be if it was moved while you were editing it), two resolves are set up against the corresponding "move/add" revision -- a content resolve to merge its contents with your edited workspace file, and a filename resolve to move your edits into the new depot path.  When you do an automatic resolve, it will be as if you used "p4 move -f" as I described in that earlier blog post, except you don't need to figure out for yourself where the file went; it will just fix itself.

	#612073 (Bug #64526) * **
	    'p4 reconcile' and 'p4 status' will now attempt to convert
	    'add' and 'delete' actions into paired 'move/add' and 'move/delete'
	    actions by comparing the added client files to the depot versions
	    of their missing counterparts.

This change is so quiet that you might not notice it, but it solves a pernicious problem, which is files not being recorded correctly as "moved" if they were moved offline.  When this happens, the problem isn't immediately apparent to the person submitting the change, but it can make life difficult for other people trying to merge in other changes -- for example, the feature described above that makes it possible to resolve against a moved file won't work if the file wasn't recorded as having been moved.

No special flag is needed to enable this new behavior; if you do a "reconcile" and some of the files show up as potential "adds" while others show up as "deletes", we will automatically do comparisons between the new files and the missing files to see if any of them might actually be the same file, and if they're similar enough, we link them up as if you had used "p4 move" to open them.  The output of "reconcile" and "status" will include a "... moved from" line when this happens so that you can preview how exactly we decided to match the files up before you submit them (you can also use "p4 resolved" after opening the files).  The "similar enough" thresholds can be tuned via these undoc configurables (see "p4 help undoc"):

        dm.status.matchlines    50 Min % matching lines to match moves
        dm.status.matchsize     10 Max size % difference to match moves

With these default values, we require text files to share 50% of their content in order to count as "similar enough" (if there are multiple candidates, the highest percentage wins), and we won't waste time comparing them at all if one is more than 10% larger than the other.

	#616528 **
	    The new 'p4 integrate' engine made available in 2011.1 and 
	    refined in subsequent releases is now the default.

This change won't affect sites that already have "opted in" to (or explicitly "opted out" of) the new engine in an earlier release by setting the dm.integ.engine configurable.  Sites that haven't set the configurable will have the new engine enabled after the upgrade, permitting renamed files to be merged with counterparts that have not yet been renamed (absolutely critical if you have development happening concurrently with refactoring in other branches).  This feature is described in more detail in another earlier blog post (https://web.archive.org/web/20150410102145/http://www.perforce.com/blog/110602/merging-moves).