libticables: rework packet logging and dissection

[debrouxl]

The direction-less, nondelimited raw hex data logger dump, reparsed from text in order to dissect protocols (twice when CABLE_USB was used: an attempt to dissect both DUSB and NSP is made, never mind the fact that only one of them is valid in > 99% of cases), is, uh, strongly disappointing.
What's more, it's not new that there is some dissection code in both libticables and libticalcs, with some near-duplication of information:

• libticables::hex2dusb.c::opcodes / libticalcs::dusb_vpkt.c::vpkt_types
• libticables::hex2nsp.c::sids / libticalcs::nsp_vpkt.c::sid_types

All of that needs a good refactor and improvement. Before thinking of APIs, let's discuss about goals and high-level implementation ideas.

Goals:

• adding direction, cable, delimiter, possibly timing information to the raw hex dump;
• logging and dissecting higher-level protocols on the fly, with direction, cable, possibly timing information;
• reducing code duplication.

Implementation ideas:

• adding two layers of chainable packet hook callbacks:
  • at the rpkt layer, in libticables, fired from ticables_cable_send() and ticables_cable_recv(), on both sides of the calls to CableFncts.send() and CableFncts.recv(). Rationale:
    • before passing a rpkt's data to CableFncts.send(): for timing information and data, but it could even be leveraged for packet content manipulation purposes;
    • after passing a rpkt's data to CableFncts.send(): for timing information, this way, the return value can be stored;
    • before receiving a rpkt's data from CableFncts.recv(): probably the least useful one, maybe for logging timing information ?
    • after receiving a rpkt's data from CableFncts.recv(): again, besides the data the return value can be stored;
  • at the vpkt layer, in libticalcs, the same kind of hooks, fired from many more functions. DUSB and NSP could use further refactor in that area ? Understandably, multiple functions build and consume small raw control packets without going through the vpkt data packet splitting layer;
• using the vpkt hook system (remember: it can't be done with the rpkt hook system due to fragmentation) to reimplement transparent packet dissection (and allow for possibly non-transparent packet validation), purely on the libticalcs side, where the entire dissection code should live (and where it was already partially reimplemented in the meantime).

The way to expose callbacks to the user is TBD for some of the callbacks. As mentioned above, callbacks should return a value to allow filtering / chaining.

test_ticalcs_2's ability to perform dissection of single packets from given hex strings was implemented in the meantime. Does it make sense to additionally specify packet direction ?