WL#3683: Increase number of data nodes from 48 to 64

Increase number of data nodes to at least, make it
possible to easily increase it up to 127 nodes and
set it to a maximum of 64 data nodes.

This is to prepare for a benchmarking at a site with
128 cores, thus making it suitable to use 64 cores for
data nodes and 64 cores for MySQL Servers and benchmark
generators. Scaling this parameter also makes it easy
to test with even bigger clusters.

The following signals need to have code when received
from older versions and when sent to newer versions
handling some signal remappings.

CM_REGREQ
CM_REGCONF
CM_REGREF
CNTR_MASTERCONF
CNTR_MASTERREQ
FAIL_REP
NODE_FAILREP
MASTER_GCPCONF
STOP_REQ
PREP_FAILREQ
PREP_FAILREF

START_LCP_REQ
CNTR_START_CONF

All of those signals require remappings since they
contain a bit mask with all data nodes in the cluster.
Most of the signals actually only contain this bitmask
as the last part of the signal and in these cases it 
is only necessary to clear the bits when receiving them
from older versions. It isn't necessary to do any handling
at all when they are sent to older versions since these
versions will anyways only copy the first part of the
bitmask and will not care about the overflow bits.

There are 2 signals that contain multiple bitmasks and
these needs some remapping both when received from older
versions and when sent to older versions.

Then one has to handle the Sysfile in DIH. This currently
sends its data in a fixed format, so here one needs to
change it to a dynamic format in the signal while maintaining
the fixed format internally.

Finally if one wants to extend number of data nodes beyond 127
then it is necessary to make READ_NODESCONF a long signal. It
is not required to do any upgrade code for this since it is a
local signal.

Special care needs to be taken with regard to CM_REGREQ and
CM_REGCONF are the first signals sent, even before the
NodeState has been set where version number is kept. However
both of these signals carry the version number in the signal
so this isn't really an issue.

A simple way of checking which version sent the signal in those
cases is to simply check the signal length.

The signals CNTR_MASTER* were removed already in version 4.1 and
so all references to these signals can be removed as a cleanup