Latest R14 XDG updates

The latest starttde update and new r14-xdg-update script were pushed to GIT in hashes 6ebf92cb and 5464fc6f. All changes revolve around R14 XDG compliance updates. I figured pushing to GIT was easier for folks to test rather than post as attachments to a bug report. I moved the R14 XDG compliance updates to a new script named r14-xdg-update. In the GIT sources the new script is added to tdebase/r14-xdg-update and is installed to $PREFIX/bin, just like starttde. The new script can be run stand-alone. starttde now calls this new script rather than perform the updates directly. I updated the migratekde3 profile migration shell script in bug report 709 and pushed in GIT hash 6ebf92cb. In the GIT sources the migratekde3 script is added to tdebase/migratekde3 and is installed to $PREFIX/bin, just like starttde. This script is a stand-alone script and is not run anywhere automatically. Compared to the initial XDG update snippets in starttde, the new r14-xdg-update script performs the following: * Error checking against sym linked profile directories (a corner case but needed). * Usage of a verbose X message box to warn about a sym linked profile directory, why an R14 XDG compliance update will not occur, what fails to function properly because of that missing update, and possible remedies available for the user. * When run directly from the command line, r14-xdg-update asks the user to automatically break the sym link, and then will ask whether to migrate a KDE3 profile. * Nominal validation tests that the XDG updates succeeded. When failures are detected then an X message box appears for each type of failure, thereby informing the user specifically what needs repair. * Supporting a command line parameter named "force" that allows users/administrators to run the r14-xdg-update script even when the kdeglobals Updated key value is set to true. * Fixed a few bugs found along the way. * If all goes well, then the user sees nothing and everything should just work. I have been testing all afternoon. :-) Everything is more robust, but I won't pretend I anticipated all usage methods or corner cases or that I found all bugs or did not introduce new bugs. I have not yet added anything related to test the XDG updating against administratively locked files and directories. I am open to suggestions. I need to review the specifications of what can be locked in a Trinity profile and how that likely affects the XDG updates. There are some "TODO" notes in the new r14-xdg-update script. Please help with testing and to improve the scripts! Darrell