transport: use ftrace ringbuffer instead of relayfs

There have many advantage to use ringbuffer, instead of relayfs.

- rb is more flexible than relayfs, like we can control consume behaive
  in rb, but we cannot do this in relayfs

- rb have builtin clock functionality, easy to output correct
  event order in kernel

- event type parse would be more easily in rb(like ustack parse)

- make ktap have no extra dependence on relayfs

- more effient in pipe_read, which relayfs don't support

- splice read already support in rb, relayfs don't support

- rb already support snapshot functionality, relayfs don't support

- using rb would be more easy to integrate with tracing infrastructure
  in kernel

- rb is more stable than relayfs, relayfs will make system hang when tracing
  all tracepoints in system(using trace "*:*"), rb don't have this issue
  (relayfs patch still not accepted yet)

- More...

This commit also remove the "use_ftrace_rb" option, because ringbuffer
already is default transport mechanism.

Signed-off-by: Jovi Zhang <bookjovi@gmail.com>
rename interpreter/transport_rb.c to interpreter/transport.c

ringbuffer is default transport mechanism for ktap now.