Remove binaryEdit::deleteBinaryEdit

[hainest]

This moves the same functionality into the destructor and prevents possible memory corruption when its usage would promote in-place object reuse. Originally part of #317.

[hainest]

https://bottle.cs.wisc.edu/search?dyninst_branch=PR866

No new regressions (the ones on ulna are unrelated).

[hainest]

@n738cu @mxz297 @sashanicolas @kupsch @bigtrak

We have generally considered the internal headers (e.g., dyninstAPI/src/binaryEdit.h) to not be visible to the user; these headers are never exported to dyninst_install/include during installation. However, the binaryEdit type is leaked through BPatch_binaryEdit::lowlevel_edit() which is visible to the user. There are many such members in user-facing types that expose the underlying Dyninst interfaces that we actually don't want to be public. Should we just ignore this and continue to treat these internal interfaces as mutable with a big CAVEAT EMPTOR to the user of something like BPatch_binaryEdit::ll_edit(), or do we want to gradually break these leaked internal APIs?