Ensure that xprofile fields have a default can_delete value of 1.

[7419] fixed a long-standing bug that prevented the can_delete value from being
saved when creating/editing an xprofile field. However, it uncovered a new bug,
which is that new xprofile fields were being created without specifying that
the default value of `can_delete` should be 1. As a result, all new fields
were being created as non-deletable (and, in fact, non-editable; see #5237 for
more details).

See #5237

git-svn-id: https://buddypress.svn.wordpress.org/trunk@7563 cdf35c40-ae34-48e0-9cc9-0c9da1808c22
Prevent admin fiddling with Fullname field with properly narrow conditions.

BP prevents admins from editing the visibility and field type settings of the
Fullname field, because BP needs it to be public and a textarea. However, BP
was enforcing this edit block by checking the `can_delete` flag of the
BP_XProfile_Field object. In practice, it's usually the case that only field 1
will have the value of `can_delete = 0`. However - especially due to changes in
[7419] - other fields can have `can_delete = 0` as well. The edit block should
therefore be more specific, based on the ID of the field rather than on the
value of can_delete.

Fixes #5237

git-svn-id: https://buddypress.svn.wordpress.org/trunk@7564 cdf35c40-ae34-48e0-9cc9-0c9da1808c22