XSVF: use svf_add_statemove()

XSVF improvements:

 - Layer parts of XSVF directly over SVF, calling svf_add_statemove()
   instead of expecting jtag_add_statemove() to conform to the SVF/XSVF
   requirements (which it doesn't).

   This should improve XSTATE handling a lot; it removes most users of
   jtag_add_statemove(), and the comments about how it should really do
   what svf_add_statemove() does.

 - Update XSTATE logic to be a closer match to the XSVF spec.  The main
   open issue here is (still) that this implementation doesn't know how
   to build and submit paths from single-state transitions ... but now
   it will report that error case.

 - Update the User's Guide to mention the two utility scripts for
   working with XSVF, and to mention the five extension opcodes.

Handling of state transition paths is, overall, still a mess.  I think
they should all be specified as paths not unlike SVF uses, and compiled
to the bitstrings later ... so that we can actually make sense of the
paths.  (And see the extra clocks, detours through RUN, etc.)

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>

src/svf/svf.h

@@ -24,4 +24,25 @@
 
 extern int svf_register_commands(struct command_context_s *cmd_ctx);
 
+/**
+ * svf_add_statemove() moves from the current state to @a goal_state.
+ *
+ * @param goal_state The final TAP state.
+ * @return ERROR_OK on success, or an error code on failure.
+ *
+ * The current and goal states must satisfy svf_tap_state_is_stable().
+ * State transition paths used by this routine are those given in the
+ * SVF specification for single-argument STATE commands (and also used
+ * for various other state transitions).
+ */
+extern int svf_add_statemove(tap_state_t goal_state);
+
+/**
+ * svf_tap_state_is_stable() returns true for stable non-SHIFT states
+ *
+ * @param state The TAP state in question
+ * @return true iff the state is stable and not a SHIFT state.
+ */
+extern bool svf_tap_state_is_stable(tap_state_t state);
+
 #endif /* SVF_H */