Also document the surprising behaviour that the times configured
`dirty_decay_ms`/`muzzy_decay_ms` have no effect unless
`background_thread:true` is given if the process is sleeping.
I was very surprised when I had a process waiting for user
input sitting around at 100 GB RES memory,
and `dirty_decay_ms` not returning the memory after the default
10 seconds, but `dirty_decay_ms:0` fixing the problem immediately.
I was even more confused that changing the time configured by
`dirty_decay_ms` seemed to be completely ignored by jemalloc,
until I got the explanation from
https://github.com/jemalloc/jemalloc/issues/2688#issuecomment-2464775694
Personally I think the default-on of `dirty_decay_ms` is questionable,
as I encountered the problem documented here with
"This can lead to out-of-memory crashes ..."
where my program needed 100 GB for some processing, freed it,
and then invoked a child process that also needed 100 GB RAM;
the parent program continued to sit at 100 GB RES usage
and thus was OOM-killed, creating a bug where none should be
(as the parent process freed all memory exactly right).
This commit at least documents the impact of this questionable default.
