trim: clean up help output

Most of the help options have a blank line between descriptions
but a couple did not. A uniform output is more readable.

Added '\n'
between --deps and --no-deps
and
between --print-callset and --trim-spec

Signed-off-by: Lawrence L Love <lawrencex.l.love@intel.com>
apitrace: Allow multiple --calls and/or --frames input options

Input for multiple files or ranges that seemed intuitive did not work

Only initialize CallSet list on first option call. If the option is
repeatedly used, continue adding to the same list.
e.g., apitrace trim --calls=@foo.calls --calls=0-20 --calls=...

The "CallSet::CallSet(const char *string)" constructor determined if the
option was a file or a range and then made the relative call to populate
the CallSet list. Rename that constructor to a public member function
"CallSet::merge(const char *string)" and call it from the command line
parser istead of constructing a new object each time the option is used.
In the renamed "merge" function, add a check to create the new CallSet
object only when the option is called the first time.

Modified modules that use this option: trim, dump, pickle, retrace

Signed-off-by: Lawrence L Love <lawrencex.l.love@intel.com>
apitrace trim: Remove memory leak in FastCallRange objects

A CallSet class contains a FastCallSet member which in turn contains
a FastCallRange member. On instantiation, the FastCallRange object
allocates memory. Instances were seen where, given CallSets x and y,
"x = y" would occur. Without overloaded operators for assignment and
copy, the pointers to allocated memory would be overwritten by
assignment or copy. In addition, the FastCallRange class had no
defined destructor to free its allocated memory when going out of
scope

Using Valgrind with a 56.3MB trace file and the command
    aptrace trim --calls=<TRIM CALLS> <trace file>

TRIM CALLS                      LEAKED BYTES
----------------                -----------------------
10                                  704 in 5 blocks
1-1700510/2                     1690856 in 8589 blocks

Attempts to add assignment and copy operators and a destructor
did not fully fix the problem. Testing in apitrace-tests showed
some tests failing. It turns out that pointers to FastCallRange
objects are held and referenced from multiple locations due to
the implementation for a skip list. If an object referencing a
FastCallRange* went out of scope, or deleted it explicitly while
another one was intending to use it, the freed memory would be stale.

Another attempt was made to use std::shared_ptr but the required
"std=c++0x" compile option broke the build in another module
(glretrace). Instead of modifying the build scripts, the option
was made to add a "FastCallRangePtr" reference counting class for
FastCallRange objects.

The FastCallRangePtr reference counting class is an implementation
of a simple reference counting class modified from an example given
at http://www.parashift.com/c++-faq/ref-count-simple.html
It is used as a friend class of FastCallRange. It keeps track of
the number of references for a given FastCallRange* and when the
FastCallRange* is no longer referenced the FastCallRange object is
automatically deleted.

All tests in apitrace-tests pass and the above examples with
different trim calls end up with 0 bytes leaked (with the
additional cli/cli_trim.cpp patch)

This implentation gives FastCallSet access to its FastCallRange
pointers. Consequently operators "->" and "*" do not need to be
defined for the FastCallRangePtr reference counting class but does
so in order to minimize the diffs in code changes (note that
std::shared_ptr also gives access to the raw pointer).

If we want to hide the FastCallRange* pointer from FastCallSet, we
need to add an iterator that allows the address of a non-allocated
FastCallRange object (i.e., FastCallSet::head).

Signed-off-by: Lawrence L Love <lawrencex.l.love@intel.com>
apitrace trim: plug memory leak in trim_trace() (cli_trim.cpp)

On final loop of 2nd pass, "delete call" was omitted.

There is a check for the final call in both the 1st and 2nd pass.
But in the 2nd pass, "delete call" was ommited. Added it to plug
the leak.

Signed-off-by: Lawrence L Love <lawrencex.l.love@intel.com>