Revert "sourcescanner: Do some fast path checks on the filename"

This reverts commit 8c0ca4717d834a6c578579656683c55ea22a06f4.
The "fast" path doesn't seem to work at all. Testing shows creating
Gtk-3.0.gir still takes about 30 seconds with this (even on
a Linux box)...

https://bugzilla.gnome.org/show_bug.cgi?id=710320
Revert "sourcescanner: Avoid scanning files when doing a macro scan"

This reverts commit 77fcc8fa47d63f58b2c3f6216a0493e42f6d44b3.
Will be not needed in about 2 patches...

https://bugzilla.gnome.org/show_bug.cgi?id=710320
giscanner: restore linemark filename unescaping

This was broken in 0d6db7114a176c2d24a19a2d6a570aab406608ac
where the unescaped filename was still computed but
no longer used...

https://bugzilla.gnome.org/show_bug.cgi?id=710320
giscanner: speed up SourceScanner().parse_files()

Was looking around a bit and noticed about 2/3 of
g-ir-scanner time is spent in SourceScanner().parse_files().

Some profiling quickly shows most of that 2/3 is used
by gi_source_scanner_add_symbol() where it creates a whole
bunch of GFile instances just to compare paths and throw
them away again. With this a scanner instance now maintains
a hash table of GFile instances instead of a list of file
names, so comparing those paths can be reduced to a fast
g_hash_table_contains() call.

This makes "g-ir-scanner <whole_bunch_of_options> --output Gtk-3.0.gir"
complete in about 10 seconds on my box instead of about
30 seconds (both best of 3 runs).

https://bugzilla.gnome.org/show_bug.cgi?id=710320
giscanner: remove g_realpath

giscannermodule expects file names to be canonicalized and
symlinks to be resolved (most likely to support users of
symlinked /usr/local). Instead of computing absolute and real
paths all over the place, we can do this once on entry
in SourceScanner().parse_files() and SourceScanner().parse_macros()
and clean the rest a bit...

https://bugzilla.gnome.org/show_bug.cgi?id=710320