have slurm srun command installed on a cray system instead of the wrapper.

to function as desired.

The `.rst` extension stands for reStructuredText, one of the markup formats
supported by github.  The tool they use to render your `README.*` and the list
of markup languages it supports can be found here:
    https://github.com/github/markup

reverted more of the change from Gerrit since the last revert made functions that aren't used anymore.

This continues the conversion of the cont_id from 32bit to 64bit,
 * updated slurm_container_find() to return u64 in order to match type of container ID;
 * updated slurm_proctrack_ops() to match the update of u32 -> u64 container ID in the
   slurm_container_xxx() functions,
 * miscellaneous type conversions from/to u64,
 * using "%"PRIu64"" for printing 64 bit.
Patch 01_proctrack-64-bit-conversion.diff from Gerrit Renker

Minor mods to man page html generation

Reverted back the change in get_basil_version, and made it a static var, only compile checked so far.

    scripts.

    command. Dependent upon .rpmmacros parameter of "%_with_srun2aprun"

Just use whichever StorageType plugin the user specifies to the configurator

Patch from Bill Brophy

    --cpus-per-task option. Patch from Martin Perry, Bull.

This allows scripted modification of job records, by exposing the
 * job_ptr->direct_set_prio
 * job_ptr->priority
 * job_ptr->details->nice
fields to the job_submit.lua script.

This allows the job_submit plugin to directly set priority values. If it
assigns a priority value different from 0 and NO_VAL, the priority is marked
as "fixed" via job_ptr->direct_set_prio.

To enable this, the permission check for directly set priority is now done
before calling the job_submit plugin, which in addition also allows to 
influence the nice value of the job via the plugin.

This reorders the code of _job_create() to the effect that the job_submit plugin
is able to put a job on hold (by setting the job priority to 0). To prevent the
user from releasing such jobs, jobs put on hold by the job_submit plugin use
WAIT_HELD rather than WAIT_HELD_USER.

This increases robustness in releasing ALPS reservations. Previously
the reservation was only released through
 * select_g_job_fini() for interactive (salloc) sessions;
 * batch_finish() by slurmstepd for batch sessions.

This introduces a single point of failure for batch jobs, since a failure
of batch_finish() would mean that the reservation could only be released
much later, through the detection of orphaned ALPS reservations in
basil_inventory().

For batch jobs that terminate normally this means that the RELEASE method is
called twice: first in job_complete(), and then in batch_finish(). The Basil
1.2 design document by Ben Landsteiner (dated 15 Feb 2011) suggests in section
3.3.5 repeated calls of RELEASE as one possible way of improving the response
of the RELEASE method. There will be additional "entry not found" messages in
the apschedMMDD logs, but (due to the preceding patch) not in the SLURM logs.

For jobs that have to be terminated (e.g. job_timed_out, job_requeue, job_fail),
this patch will mean that the RELEASE is called much sooner and thus is 
expected to improve efficiency.

For interactive salloc sessions that are cancelled via scancel, there is now
no longer a warning message about the no longer existing ALPS reservation
(since the release happens first through select_p_job_signal and then through
 job_complete -> deallocate_nodes -> select_p_job_fini).