gdb: erase items from the source_cache::m_offset_cache

gdb: erase items from the source_cache::m_offset_cache

The source_cache class has two member variables m_source_map, which
stores the file contents, and m_offset_cache, which stores offsets
into the file contents.

As source files are read the contents of the file, as well as the
offset data, are stored in the cache using these two member variables.

Whenever GDB needs either the files contents, or the offset data,
source_cache::ensure is called.  This function looks for the file in
m_source_map, and if it's found then this implies the file is also in
m_offset_cache, and we're done.

If the file is not in m_source_map then GDB calls
source_cache::get_plain_source_lines to open the file and read its
contents.  ::get_plain_source_lines also calculates the offset data,
which is then inserted into m_offset_cache.

Back in ::ensure, the file contents are added into m_source_map.  And
finally, if m_source_map contains more than MAX_ENTRIES, an entry is
removed from m_source_map.

The problem is entries are not removed from m_offset_cache at the same
time.

This means that if a program contains enough source files, GDB will
hold at most MAX_ENTRIES cached source file contents, but can contain
offsets data for every source file.

Now, the offsets data is going to be smaller than the cached file
contents, so maybe there's no harm here.  But, when we reload the file
contents we always recalculate the offsets data.  And, when we
::get_line_charpos asking for offset data we still call ::ensure which
will ends up loading and caching the file contents.

So, given the current code does the work of reloading the offset data
anyway, we may as well save memory by capping m_offset_cache to
MAX_ENTRIES just like we do m_source_map.

That's what this commit does.

There should be no user visible changes after this commit, except for
ever so slightly lower memory usage in some cases.