Properly track resv->[core_cnt|node_cnt] memory.

Testing with valgrind I found some cases where memory leaked or program
got SIGSEV. This was due to bad memory tracking of these resv_desc_msg_t
members. Some example requests that now end up with the expected behavior
and no memory errors nor leaked memory:

scontrol create reservationname=test start=now end=now+1day users=alex ...
	- nodecnt=2
	- nodecnt=badvalue
	- nodecnt=2 tres=node=1
	- nodecnt=2 tres=node=badvalue
	- corecnt=1
	- corecnt=badvalue
	- corecnt=1 tres=cpu=2
	- corecnt=1 tres=cpu=badvalue

sview reservation creation/update.

Ideally we should use slurm_free_resv_desc_msg() instead of tracking each
resv_desc_msg_t member separately, but this function unconditionally xfrees
each member, even if they have a value but memory was not allocated, thus
receiving a SIGABRT.

Bug 2329