Use the word "symbol" instead of "tag" in the UI and documentation

For users a tag is <this> so the naming can be confusing.

The only exception where we probably shouldn't use the word symbol is the
"tags file" (*.tags) containing global tags - this has already the "tags"
extension and is more related to ctags and using "symbols file" is a bit
strange in this case.

As a result, the only places where this patch leaves the word "tag" are:

* phrase "tags file(s)"
* phrase "tags parser(s)"
* documentation mentioning the "tags" directory
* documentation mentioning the *.tags extension

and of course where it means the HTML/XML markup <thing>. The rest of the
uses of the word "tag" is replaced with "symbol".

Documentation is updated accordingly.

Fixes #579.

Closes #496.

Based on PR#496 by @DThought, thanks.

Colourise only the visible area when highlighting typenames

Indentation per official style guide:
https://github.com/rust-lang/rust/blob/master/src/doc/style/style/whitespace.md

Closes #595.

Closes #858.

Update Korean Translations

748137bd improved return types, but as
this test case was added in parallel it wasn't updated as needed for
the new, more correct, results.

Rewrite scope completion v3.

Closes #488 and #505.

c++: Fix parsing of C++11 raw string literals.

C, C++, C#, D: Improve return type and var type recognition.

lt translation updated

Remove obsolete scripts/plugin_test.c

We only perform search based on variable name so if a variable is e.g. of
the type std::Foo, we can drop the std:: prefix and search only for the
Foo type.

This is far from perfect and contains a lot of guessing.  It showed
good results based on our tests cases, fixing several issues and not
introducing any more issues (admittedly, after working around a subtle
one regarding D static ifs).

Closes #845.

GBoxed types

scintilla: add scintilla_object_* to the plugin api

See http://en.cppreference.com/w/cpp/language/string_literal

Also, don't perform subtractions to check pointer bounds, to avoid
unsigned value wraparound.  This is very unlikely as it would either
mean a very large `nth` value or a very small value for the current
line pointer, but better safe than sorry.

This ties related logic together, making it less of a hack and easier
to maintain, as well as accessible by all parsers if needed.

See http://en.cppreference.com/w/cpp/language/string_literal

Closes #877.

---

This contains a pretty ugly hack to fetch the previous character, in
order not to get fooled by string concatenation hidden behind a macro,
like in `FOUR"five"`, which is not a raw string literal but simply the
identifier `FOUR` followed by the string `"five"`.

While this may sound uncommon, it is not and lead to complaints [2][3]
when Scintilla [1] broke this when they introduced C++11 raw string
literal support themselves.

The implementation here still contains a bug with line continuations: a
raw literal of the form:

```c
const char *str = R\
"xxx(...)xxx";
```

is not properly recognized as such, although it's perfectly valid (yet
probably very uncommon).  For the record, Scintilla has also suffers
from this but nobody complained about it yet.

[1] http://scintilla.org/
[2] https://sourceforge.net/p/scintilla/bugs/1207/
[3] https://sourceforge.net/p/scintilla/bugs/1454/

This script was used in the nightly builds to verify plugins will load
and have no undefined symbol references. Since the new way plugins
are built and linked, this is no longer necessary.
Additionally, this script won't work with new style geany_load_module()
plugins.

Because the stash_group_new() is an exported API, it has to be at least a boxed
type to be usable for gobject introspection. The boxed type uses reference
counting as opposed to memory duplication.

The obligatory stash_group_dup() is not exported (doesn't have to).

Because the tm_source_file_new() is an exported API, it has to be at least a
boxed type to be usable for gobject introspection. The boxed type uses
reference counting as opposed to memory duplication.

The obligatory tm_source_file_dup() is not exported (doesn't have to).

Analogous to their legacy counterparts. Also required for gir-bindings
generated via g-ir-scanner.

First, the search for existing type with the given scope should be done
also for namespaces.

Second, with the string operations we get no scope as empty string ""
but the rest of TM functions expect scope to be set to NULL in such
case. Fix that.

There may be duplicate tag names in the list e.g. when performing namespace
search and overloaded methods are found.