after cloning a MIDI region, mark the source file as non-removable. Fixes reports about missing MIDI files on the forums and IRC
after cloning a MIDI region, mark the source file as non-removable. Fixes reports about missing MIDI files on the forums and IRC
redesign technique for naming/creating regions for MIDI clone (or other non-capture driven MIDI region creation operations).

See comments in Session::new_midi_source_name() for details.
dramatic change in logic and naming for operations related to adding a MIDI region on demand and cloning/unlinking

Existing code would cause data loss due to creation of two Source objects referring the same path, one with removable flags and one without. Careful code review suggested a variety of thinkos, function naming problems and other confusion that caused this. I have tried ot extensively comment what is going on with these operations, because it is one key area in which MIDI differs from audio: with audio, capture is the only way to add a new audio region, but for MIDI there are GUI input events that can add a new region.
further code simplification and rationalization related to MIDI source/file renaming
check whether a source with the same path exists in session list not just on disk.

This is intended to catch a potential wierd condition where a source exists as a stub, but has not yet been written to disk,
and then a new source is created with the same path. Currently it is not understood how/when this might happen
merge 5764970709f15e85ec30c9cea89c318eb8114c58 from cairocanvas as final(?) change related to data loss