ptserver: Fix RemoveFromSGEntry hentry memcpy

In this function, hentry is the "previous" continuation entry that we
looked at, and centry is the "current" continuation entry. We keep
track of the previous continuation entry in case we need to update its
'next' pointer, which we do if we free one of the continuation entries
because it is empty after the removal.

So, this memcpy is supposed to copy the current entry to the previous
one, but the arguments are flipped, so we just copy zeroes to centry
(since hentry is initialized to zeroes early on in the function), and
hentry never gets set to anything besides zeroes.

The effect of this is that whenever a ptdb entry has more than one
continuation entry, and we free up any of them after the first one via
RemoveFromSGEntry, the previous continuation entry becomes blanked
(though the 'next' pointer should still be correct). This means the
membership information for that group is not recorded correctly, as it
loses a chunk of the IDs that it is a member of. The reverse mapping
should still be intact (the parent groups have a pointer to the
sub-group), but the group probably doesn't function correctly.

The reason this happened is because of the confusing conversion from
bcopy to memcpy. Most of the instances of bcopy/bcmp/bzero/etc were
converted (correctly) back in commit c5c521af, but the supergroups
implementation was added afterwards, in 8ab7a909, and contained a
bcopy reference. This bcopy was converted to memcpy in 58d5f38b, but
the argument order was not corrected, causing this bug.

To fix this, just flip the first two arguments of the memcpy. Just get
rid of the casts here, too, to match the code in the non-supergroups
RemoveFromEntry and elsewhere.

Reviewed-on: http://gerrit.openafs.org/11340
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: D Brashear <shadow@your-file-system.com>
(cherry picked from commit 2d89d447c8b00a40d3fc559813fe31c177da164b)

Change-Id: I78b80cb7b043c9d1562b543906a593a985020b43
Reviewed-on: http://gerrit.openafs.org/11352
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de>