Editing xprofile fields resets their positions to the bottom

[junsuijin]

Any change to an xprofile field or its options will cause it to reset in position, to the end of the order.
The included patch fixes this issue along with some other typos in xprofile admin (blank space in description field, invalid checkxbox type check, var_dump comment, unused $options = $this->get_children();).

The patch also does a sanity check in the normal delete function to prevent deletion of fields where 'can_delete' is false, and to prevent deletion of the first option, since that invalidates a field with options.

This patch also causes radio options to automatically select the first option on field creation, as is the intended behavior.

Finally, the patch makes a first attempt at giving the forms some stickiness, for the most common situation where the profile field has not yet been saved to the database, and the user is most likely to make a mistake that would otherwise cause them to lose anything they had input if they end up with an invalid submission.

It is also possible to lose changes when altering an already-saved profile field to the point of unacceptability, but this will have to be addressed in the future.

I've been staring at this for quite awhile now so it'd be nice to get some others to test it as well. I think it's at least an improvement, but the acceptability of all of its parts remains to be seen.

[apeatling]

Tested the patch, it does what it says. I'm going to commit this since it fixes a number of outstanding annoying quirks. The admin interface and code for Xprofile needs a complete re-write, probably in the next version.

[apeatling]

(In [1907]) Fixes #1040 props junsuljin