Changes on APL-ChangeSequence, from 1.6 to 1.12

bug fixes:
	- mnu #asSymbol when trying to backup changed code for methods with nil protocol
	- Loss of new elements in a Changes editor was possible
	- changes referring to discarded source code after condense changes
		(some change objects cannot be resolved to source code,
		especially method changes followed by a method remove,
		but also method changes referring to renamed classes)
	- class renames have to be propagated to change sequence elements
		(method changes might refer to old names of renamed classes until 
		newly compiled)

code maintenance:
	adapt to new handling of source/changes file references in Change objects 
	since version 1.10 of ExternalSource (version 1.12 for VisualWorks 2.0);
	reduced output when filing out changes (avoid superfluous protocol headers)

removed selectors:
	ChangeSequenceController>addDoIt
	ChangeSequence>updateChanges

NOTE:
	The new code of APL-ChangeSequence propagates class renames
	immediately to all change sequences. The old code did not do so.
	If you have class renames pending in application changes, then you
	will have to revise them manually in order to ensure consistency.
	Check applications for invalid class references by inspecting the
	value of

		"ApplicationManager select: [:ap |
			(ap changes findFirst: [:chg | chg classObject == nil
					and: [chg className isEmpty not]]) > 0]"

	Open an Application Browser on each of the applications found
	and view their changes with menu item 'spawn> changes'.
	You may modify change objects with the help of an inspector
	(opened with 'edit> inspect' on the Changes Editor menu)
	or by evaluating

		"self changes renameAllClass: oldClassname to: newClassname"
	or
		"self changes renameClass: oldClassname to: newClassname"

	whatever may be appropriate (see method comments for details).
	The receiver 'self' is the application itself.