For example:
     Nodes=nid00001 CPU_IDs=2-3 Mem=1000 GRES_IDX=gpu:alpha(IDX:2)
     Nodes=nid00002 CPU_IDs=0-1 Mem=1000 GRES_IDX=gpu:alpha(IDX:0)

Add new WHOLE_NODE_REQUIRED/WHOLE_NODE_USER/WHOLE_NODE_MCS macros
to help cleanup tests rather than rely on magic values.

Warning: these are similar to the JOB_SHARED_ macros, but the logic
for zero vs one is different. USER/MCS are the same across these.

No functional change.

Bug 3291.

If GRES are configured with file IDs, then "scontrol -d show node" will
    not only identify the count of currently allocated GRES, but their specific
    index numbers (e.g. "GresUsed=gpu:alpha:2(IDX:0,2),gpu:beta:0(IDX:N/A)").

Bug 3267.

Termination can race against step creation if, e.g., ill-behaved SPANK plugins
are in use.

Bug 3248.

No change in logic, just clearer messages

Error being generated on 32-bit system

Added SchedulingParameters option of "bf_job_part_count_reserve". Jobs below
    the specified threshold will not have resources reserved for them.
bug 3275

srun -n8 -c1 --spread-job --hint=nomultithread whereami | sort -h

would cause a core dump because the wrong variable was setup.

messages.  Hopefully this will reduce the number of messages lost when
filling up memory when the database/DBD is down.

sched/backfill plugin: Make malloc match data type (defined as uint32_t and
    allocated as int). No failures observed, if type "int" is smaller than
    "uint32_t", it could result in an invalid memory reference.

Fix API call: slurm_job_cpus_allocated_str_on_node_id() and
in turn slurm_job_cpus_allocated_str_on_node() to return correct
results for anything but first node. This was caused by missed logic
to calculate fist bit belongs to particular node. Lookup was always
starting from bit 0.

Bug 3266.

After one second of wall time, simulate the termination of all remaining
   running jobs in order to respond in a reasonable time frame.
bug 3275

Modify backfill algorithm to improve performance with large numbers of
    running jobs. Group running jobs that end in a "similar" time frame using a
    time window that grows exponentially rather than linearly. The original
    window sizes were (in units of minutes):
    0, 1, 2, 3, 4, 5, 6, 7, ... minutes
    The new window sizes are:
    0.5, 1, 2, 4, 8, 16, 32, ... minutes
    This can dramatically reduce the number of instances where the very time
    consuming "can the pending job run now" operation is executed, especailly
    if there are 1000+ running jobs.
bug 3275

Modify several NEWS items for greater clarity.

Dead code, except for four uses of safe_pack8 and one safe_pack16.
Convert those to the pack8/16 calls directly.