'breakpoints' file now shows what was written to it

Before this commit, when the 'breakpoints' was read, it showed the list
of the software breakpoints actually set at the moment (0xcc present at
the relevant position in the target's code).

The user could write to that file to add/remove breakpoint available for
use (or a range of them).

However, there was no way to see all the breakpoints the user specified
this way. Moreover, if a breakpoint was in the process of being reset
or was not chosen for setting, it would not be shown when reading the
file.

This may lead to confusion: the user might think that the system failed
to add the breakpoint (I thought so myself ;-) ).

I suppose, it is better to make 'breakpoints' file consistent w.r.t.
reads and writes and make reads show the elements of 'ranges_list',
that is, exactly what was specified by the user so far.

Besides that, a release() operation was added to the file to release
the memory allocated by open().

The file was made non-seekable as well, just in case.

Some minor changes were also made.
Removed some usused stuff; marked local things static
Handled the case when the code wakes up on a different CPU

After msleep(), the code may wake up on a different CPU. It is unclear
if the pending timer to set the HW BP on that CPU has run its function
by then, however unlikely it seems.

Now hw_bp_clear() takes care to delete all pending timers that set the
BP, on each CPU, including the current one. So even if setting of the
HW BP was pending on the current CPU, it will be cancelled properly.
(uint)(-1) is now used internally to denote "all possible offsets"

If the user writes "func+*" to 'breakpoints' file to specify all
possible instructions in "func", -1 is now used internally as the value
of the offset to denote this (rather than 0).

It is rare but possible for the first instruction in a function to be
of interest to RaceHound too, so using 0 as a special value of the
offset is undesirable.
Several fixes related to 'ranges_list'

1. Adding an item that already exists is no longer permitted, same for
the removal of a non-existent item.

2. The list is now cleared and its elements are deallocated when
RaceHound is about to unload to avoid leaking memory.
Warn about a missing function only if target is loaded

One of the convenient abilities of RaceHound is that the user may
specify the desired instructions in the target to monitor before the
target is loaded. As soon as it is, they will be processed.

In this case, I suppose, RaceHound should not warn about a missing
function when the target is not loaded, to avoid confusion.
Removed dead code: bprange->func_name is never NULL then
A couple of improvements in the code that chooses insns to monitor

1. If the limit on the number of simultaneously active breakpoints is
higher than the number of candidates, use them all and do not do
randomization.

2. Fixed: the randomly chosen breakpoints were not marked as chosen,
so the randomization might not have worked as expected.
Revisited handling of software BPs and of the related data

1. The instances of sw_used struct can no longer disappear at a whim.
They are refcounted now. Even if the user requests to delete them or the
code that chooses the BPs to be active removes them, it should no longer
be a problem to their handlers.

Without this, I ran into use-after-free conditions on such structures
for this reason before (during the analysis of e1000 driver).

2. No need to copy function name, etc. all the time. sw_active has been
removed too.

Now the name of the function is stored in sw_available and sw_used just
refers to it.

The fields of sw_active were moved to sw_used. These structures can be
put to two lists, used_list and active_list, depending on the situation.

One entity less.

3. Fixed some memory leaks: the list items were not always destroyed.
Added missing error handling for memory allocations
Merge pull request #4 from euspectre/swbp_revisit

Revisited the code dealing with SW breakpoint and the related stuff