I think it's time to revisit how cyclictest interacts with
ftrace. Cyclictest is used not just as a measurement tool, but as a
debugging tool when we're trying to find a latency spike in the
kernel. Right now the way it interfaces with ftrace can be quite
confusing and non-intuitive. I'd like to try and simplify things
somewhat.

The most common method for debugging with cyclictest is using the -b
(--breaktrace) option, which implicitly fires up ftrace and turns on
event tracing. See that "implicitly" bothers me. And it bothers other
people when they try and make sense of the maze of ftrace options
offered by cyclictest:

	-b, --breaktrace=USEC
	-C, --context
	-E, --event
	-f, --ftrace
	-O, --traceopt=TRACING_OPTION
	-T, --tracer=TRACEFUNC
	-w, --wakeup
	-W, --wakeuprt
	--notrace
	--preemptirqs
	--latency
	--irqsoff
	--preemptoff

What I'd like to do is move from "implicit" to "explicit" when dealing
with options in general and ftrace in particular.

First, I'd like to modify the -b/--breaktrace option to do exactly
what it is supposed to do and nothing else: stop the execution of
cyclictest. That means when a latency is measured which exceeds the
specified threshold, it stops. Nothing more. It also does *not* mount
debugfs (or tracefs when we move to that) when starting up nor does it
umount the fs when cyclictest stops. This way we can use cyclictest in
scripts where the only info you need is that cyclictest hit a
threshold and stopped.

If you want further information, then use the --ftrace and/or --events
option to cause the ftrace system to be started. This means mounting
either debugfs or the soon-to-be-available tracefs, then poking values
into various entries to enable events, tracers, etc.
