Correction to hostlist sorting for hostnames that contain two numeric
components and the first numeric component has various sizes (e.g.
"rack9blade1" should come before "rack10blade1")

Previously the job would be accepted at job submit time if nodes
required for its use (e.g. in a required node list or the node
count) could not be satisfied at submit time due to an advanced
reservation. Bug #187

and is also enforced correctly

1) updated man pages to better explain how the acct_gather_energy plugins give accurate results only in case of exclusive job allocations

2) remove unnecessary defines

Split long lines, add brackets, indentation

1)updated scontrol show node to report "n/s" (not supported) for energy/power values in case  acct_gather_energy/rapl is configured and nodes do not support RAPL Previously, these values were reported as zero. The scontrol man page has been also updated to explain this.

2)updated sstat / sacct to report no value for ConsumedEnergy in case acct_gather_energy/rapl is configured, a job/step is allocated and at least one node does not support RAPL. Previously for this case, sstat and sacct reported a partial value for ConsumedEnergy.

3)updated the logging mechanism so that If acct_gather_energy/rapl is configured and a job/step is allocated any nodes that do not support RAPL, a single debug entry is made in the log file.  Previously, multiple repeating error messages were sent to the console and the log file.

job on future step creation attempts.

bgsched::runjob::Terminated::Nodes::software_error_nodes()

It shouldn't really affect the code.  It only printed out cnodes, which
most likely never really did anything.

also cause it to run if the realtime server ever goes away.

Especially for newly started jobs, the PrologSlurmctld can change
a job's QOS based upon resource allocation.

DB2 so hard.

Conflicts:
	src/slurmctld/job_scheduler.c

Problems with jobs starting on reserved nodes

Added check for preeption mode before changing time limit to 1 if flag no reserve is enabled, as this can cause a problem with jobs starting on nodes with future reservations.