Adds/changes to rmk36--Tedit-fifth-round to accommodate Notecards property list editor

[fghalasz]

@rmkaplan This is a pull request on top of your rmk--Tedit-5th-round branch. It incorporates two changes:

1. Notecards needs to be able to delete tedit-menu Fields. So I modified MB.DELETE to be able to delete fields by temporarily setting (using RESETSAVE) the WHENDELETEDFN for the field objects to NILL (instead of MB.DON'T). I used a fairly inefficient way to find the field suffix object that corresponds to the field prefix object - but it works. Maybe you have a better way to do this. Also this is probably not thread-safe - since I think the imagefns object is shared across all MB.FIELD instances, so it will have to be hardened a bit once I can get the other pieces in place.

2. The MB.BUTTONEVENTINFN/CUSTOMBUTTONEVENTFN changes I proposed the other day didn't quite handle the 'Don't return from CUSTOMBUTTONEVENTFN correctly. These changes fix that.

3. Not part of this PR, but I did notice that the code that moves the insert cursor when the user clicks on a Field pre/post label is duplicated in the MB.FIELD.BUTTONEVENTINFN and the MB.FIELD.WHENOPERATEDONFN. Is this necessary? Wouldn't the code in MB.FIELD.WHENOPERATEDONFN be sufficient to handle all cases?

[rmkaplan]

On point 1, I think it is not safe to modify the IMAGEFNS even to change the behavior temporarily of one object. We could set up 2 imagefns with different whendeletedfn methods and swap it in to the object whose deletion you want o enable.

But I think a more direct solution is to redefine MB.DON'T as (LAMBDA (OBJ) (CL:UNLESS (IMAGEOBJPROP OBJ 'DELETABLE) 'DON'T). Fields (and maybe all menu buttons) would not be deletable by default, but setting that property would change the behavior. You could put (DELETABLE T) in the button spec for deletable fields.

Alternatively, the default could be deletable, and a ropery NOTDELETABLE would suppress that.

On point 3, I put that piece of code in both places out of an abundance of caution. I believe that fields are not "selected" in the traditional sense--the action happens in the buttoneventinfn--but I wasn't sure if there was another pathway.