doc: document config_setting_t pointer invalidation on override and re-read (#298)

[SergioAtienza]

Summary

Documentation-only fix for #298, implementing the approach agreed upon in the issue discussion (documenting the invalidation rules; a behavioral reuse-in-place fix was considered and set aside because pointers to children of a replaced setting would dangle in the same way).

Two undocumented invalidation rules currently leave config_setting_t * handles dangling:

1. Override path: with CONFIG_OPTION_ALLOW_OVERRIDES enabled, config_setting_add() with a duplicate name internally calls config_setting_remove(), which recursively destroys the pre-existing setting object (__config_setting_destroy()). Any pointer previously returned for that setting or its children is left dangling, and its next use is a heap-use-after-free (CWE-416) — see the ASan trace in heap-use-after-free: config_setting_add() with CONFIG_OPTION_ALLOW_OVERRIDES silently destroys the existing setting, leaving callers with dangling pointers #298.
2. Re-read path: all three config_read*() entry points route through __config_read(), which calls config_clear() before parsing, recursively destroying the entire existing setting tree. Any pointer obtained before a re-read (the classic daemon-reload-on-SIGHUP pattern) silently dangles; none of the three manual entries mentioned this.

Changes (doc/libconfig.texi only, no code changes)

• CONFIG_OPTION_ALLOW_OVERRIDES: note that overriding destroys the previous setting object (recursively, including any children) and invalidates all pointers previously returned for it, e.g. by config_setting_add(), config_setting_get_member(), or config_lookup().
• config_setting_add(): clarify that the "already exists" NULL return applies when CONFIG_OPTION_ALLOW_OVERRIDES is turned off, and that when it is on the existing child setting is destroyed and replaced, invalidating previously returned pointers.
• config_read(), config_read_file(), config_read_string(): note that reading into a configuration discards any previously read configuration — all settings are recursively destroyed first (as with config_clear()) — so previously returned pointers become invalid and must not be used.

The wording follows the patches posted and discussed in #298, rebased onto current master (277b960; context had shifted slightly after #297).

Verification

• Both statements were cross-checked against lib/libconfig.c on current master: the override path (config_setting_add() → config_setting_remove() → __config_setting_destroy()) and the re-read path (config_read*() → __config_read() → config_clear()).
• makeinfo --no-split doc/libconfig.texi and makeinfo --html --no-split doc/libconfig.texi both build cleanly: no errors and no new warnings (the only warning, node `Lookup Differences' unreferenced, already exists on master and was introduced by docs: document differences between config_lookup and typed lookups (#242) #297). All five added notes were confirmed present in the rendered info and HTML output.

If you would like the same note added to the corresponding C++ API entries (Config::OptionAllowOverrides, Setting::add(), Config::read()/readFile()/readString()), I'm happy to include it here or in a follow-up PR.

Fixes #298

---

Discovered with DarwinFuzz — Sergio Atienza Pastor, R&D department of MTP (Métodos y Tecnología) and UPM (Universidad Politécnica de Madrid). Full report and ASan trace in #298.