Instead of a size limit of ASCIILINESZ for multi-line input now there is no
limit, a multi-line can be *any* size (and hence the key and value now
also have a dynamic size)

* there is a limit still on input line size (since multi lines are built
  from multiple lines where each line part is limited to ASCIILINESZ)
  Note: there is no limit to the size of the multi-line itself (it's
  only limited by available memory)
* all stack & static fixed string usage has been removed with the exception
  of parsing line (or a multi-line portion) input, fgets still reads into
  a fixed string buffer of size ASCIILINESZ.
Signed-off-by: NNoel Power <noel.power@suse.com>

Instead of a size limit of ASCIILINESZ for multi-line input now there is no
limit, a multi-line can be *any* size (and hence the key and value now
also have a dynamic size)

* there is a limit still on input line size (since multi lines are built
  from multiple lines where each line part is limited to ASCIILINESZ)
  Note: there is no limit to the size of the multi-line itself (it's
  only limited by available memory)
* all stack & static fixed string usage has been removed with the exception
  of parsing line (or a multi-line portion) input, fgets still reads into
  a fixed string buffer of size ASCIILINESZ.
Signed-off-by: NNoel Power <noel.power@suse.com>

The documentation disclaims support for building with a C++ compiler, so
it is reasonable to assume that the library will be built with a plain C
compiler, so the functions will all have plain C linkage.  By default, a
C++ application that wished to use libiniparser would need to wrap the
inclusion of libiniparser headers in 'extern "C" { ... }' to reflect the
C linkage of libiniparser.  Instead, place that marker directly in the
libiniparser headers, so that client applications do not need to care.
This has no effect on normal compilation of libiniparser, since the new
markers are inside a '#ifdef __cplusplus' guard, and straight C
compilers do not define __cplusplus.