context: Don't initialize filename ref string value
context: Don't initialize filename ref string value

This papers over an extremely odd bug:
In multithreaded applications, we sometimes get:
   g_atomic_ref_count_inc: assertion 'g_atomic_int_get (arc) > 0' failed
warnings, and in extremely rare occurrences (once every ~400 runs) heap
corruption can be observed (code compiled without optimizations).
This appears to be caused by replacing the already initialized
GRefString with a new one via as_context_set_filename() shortly after
the AsContext was created. Oddly enough, all functions that modify any
data in AsContext are only ever called from the same thread, and only
ever once on initialization. So adding any locking does not help.
Building libappstream with address sanitizer also yields no clues.

An extremely easy workaround for this is to simply not initialize the
GRefString with an internalized value - as it happens, that is more
correct anyway, as a NULL filename is assumed to mean that data was kept
in memory / no usable filename was set.
Of course, this does not solve the issue properly - something very odd
is going on here, which must be investigated further (there is also the
scary option that the problem lies elsewhere and may manifest itself
again in a different form later...)

ximion/appstream,ximion/appstream,ximion/appstream,ximion/appstream