prepare 1.9.0beta
set release date / version for 1.9.0

beta is tagged, now for the final release.
Merge branch 'next' into r1.9
Merge branch 'next' into r1.9
Merge branch 'next' into r1.9
Fix writing the objects.cache file

A regression introduced in ae09a1a478f60484ed629d0b5e513763f67c00ae caused the
objects.cache to be written only when running in verify (-v) mode. The cache
file should be written when verify_config == FALSE.

Signed-off-by: Michael Friedrich <michael.friedrich@netways.de>
update Changelog for #4155

refs #4155
classic-ui: fixed UNICODE characters in JSON output from getting discarded #4193

function "json_encode" should handle unicode characters no properly

refs: #4193
classic-ui: fixed Generated HTML code partly invalid #3608

refs: #3608

this is a huge commit. hope html code now looks better and
is valid.

this will stay in another branch to make shure it's not
causing any trouble

Conflicts:
	Changelog
	cgi/cgiutils.c
	cgi/extinfo.c
	cgi/histogram.c
	cgi/status.c
	cgi/trends.c
	html/main.html
classic-ui: fixed statusmap popups
classic-ui: fixed more invalid html code #3608

mostly substituted "&" with "&amp;" in urls

refs: #3608
idoutils: fix segfaults on reload with multiple neb modules of the same binary

my bad, the loop did not fetch the correct next address pointer for
free'ing the module list items, resulting in a SIGSEGV.

fixed, but unveils a different problem - multiple handles of a binary
loaded via dlopen() share the same global symbol space which means that
the registered callback functions only work for the first match.

fixes #4033
nebmods: fix multiple modules sharing same symbols not receiving callback data

once dlopen() loads modules with the same name, it will make sure to
register only the first symbols, and not overriding the coming ones from
more modules of the same binary.

this is bad, as e.g. multiple idomod's will try to register the same
callback function symbols, and only the first one wins then. this is the
reason why only the first instance_name is getting populated in idoutils
database then too.

the initial handshake of ido2db with idomod only happens for the reason
of calling the nebmodule_init() function symbol (from the first module)
with different arguments, passed by the core. each module should have at
least a different instance_name defined in its idomod.cfg, so the init
function will be called with those, doing a handshake (and insert into
icinga_instances table then) then. but afterwards, no data gets received
from the callbacks not having such a diversity (how should the core then
know anyways, it's a _callback_ function called only once from symbol
space!).

basically, the root issue is an omd patch living for more than 2 years
now, but the old behaviour is now restored with this fix (plus adding a
debug idea stolen from Andreas Ericsson, thanks).
alongside fixing this, the solution is rather simple - make a temp copy
of the binary to some random name, and let dlopen actually load that
into memory. then all the registered function symbols will remain module
based and everything else works with the callbacks and so on.

as this is a behavioural change, it should get a note in Changelog once
merged into release trees.

refs #4199
Merge branch 'fix/neb-unload-4033' into r1.9

Conflicts:
	Changelog
Merge branch 'fix/json-unicode-4193' into r1.9

Conflicts:
	Changelog
add Christian Ruppert to THANKS
bump to 1.9.1
Merge branch 'fix/dlopen-mult-sym-4199' into next
Merge branch 'fix/invalid-html-code-3608' into next

Conflicts:
	Changelog