bitmap resources are disconnected from .src/.res now

tl;dr: To use a theme png in C++, add #define NAME "path/to/png" to a
.hlst and use BitmapEx foo(NAME)

Until recent changes, bitmap (png) resources were described by a define
to an arbitrary number in a .hrc with a body in a .src that contains
the file name within the theme hierarchy. The .src got compiled into
the final .res with resource ids of the hrc defines

In the C++ code the .hrc define was passed to a ResID and the resource
manager would load the resource in the final .res and suck out the
filename entry and then look that up in the theme hierarchy and load
the png from there.

Now we just consistently use the filename of the png within the theme
hierarchy as the argument to the BitmapEx constructor and bypass the
.src/.res intermediaries.

We used to parse the .src/.res files to find the list of actually used
images in LibreOffice to filter out unused icons in the themes. We want
to continue doing that, so the scheme is use is to define FOO
"path/to/the.png" in a .hlst file and include that from the .cxx and
BitmapEx foo(FOO) and add the .hlst to
postprocess/CustomTarget_images.mk and the used bitmaps are the only
ones packed by (crudely) sucking out the target of the define and
converting to the preexisting ilst format[1]

The "private:graphicrepository" url syntax e.g.
"private:graphicrepository/sd/res/minimize_presi_80.png can continue to
be used to load bitmap resources. You can use the .ilst mechanism to
ensure they are packed and not ignored as unused. (mostly java/python
pieces need this)

But support for private:resource/projectname/bitmapex/<number> and
private:resource/projectname/bitmap/<number> has been removed and
replaced with "private:graphicrepository/res/projectname/bitmapex.png"

I think this is clearer than the preceding system and I was able to
find a few png which were referenced from cxx code, but didn't exist in
our icon-themes

It's quite possible that we could now rename all the very arbitrary
filenames from e.g. sx10234.png to more reasonable names (watching out
for any that might be used from helpcontent2 or loaded via
private:graphicrepository)

[1] maybe this hlst processing/registering needs to be gbuild-ified to
be prettier