libgsf: avoid the NUL byte of REMOVE_BASE_DIRECTORY

`rules_pkg` defines `REMOVE_BASE_DIRECTORY` as the sentinel string `"\0"`, so
the `renames` attribute of `//omd/packages/libgsf:rest` contained a NUL
character. `bazel query --output=xml` serializes that as `<string
value="&#0;"/>`, but U+0000 is outside the legal `Char` range of XML 1.0, i.e.
there is no way to represent it and every conforming parser must reject the
document. As this was the only occurrence in the whole repository, a single
target made the XML output of any query covering it unparseable.

Use `strip_prefix.from_pkg("rest_filter")` instead: `_do_strip_prefix()` has a
branch for exactly this case, returning an empty path when the prefix to strip
names the TreeArtifact itself, which is what `filter_directory` produces here
(its output directory is named after the rule). The resulting mapping is the
same one `REMOVE_BASE_DIRECTORY` yields, i.e. the directory contents land
directly in the prefix path.

Verified via `bazel cquery --output=starlark 'providers(target)'`: the
`PackageFilesInfo` of `:rest` is unchanged, `dest_src_map = {"": <generated
file omd/packages/libgsf/rest_filter>}` before and after. A throwaway package
reproducing the pattern (copy_to_directory => filter_directory => pkg_files =>
pkg_tar) produced byte-identical tarballs for both variants. The libgsf tarball
itself could not be built locally for a direct comparison (`@libgsf` fails with
"configure: error: Your intltool is too old", unrelated to this change).

No functional change.

Change-Id: If759879d38ed1bed1a89a1e5212a4de706777f68