dtrace: incorrect aframes value and wrong logic messes up caller and stack

dtrace: incorrect aframes value and wrong logic messes up caller and stack

Due to a mistake in how we compensate for the potential ULONG_MAX
sentinel value being added to kernel stacks on x86_64 (by the
save_stack_trace() function), the caller was always reported as 0.

This in turn was hiding a problem with the aframes values that are
used to ensure we skip the right amount of frames when reporting a
stack, caller, and calculating the stackdepth.  Effectively, it tells
the stack walker how many frames were added to the stack due to DTrace
processing.

Orabug: 25727046
Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>