Does the issue with Cargo still linking `std` for a `#![no_std]` crate when the
   `dev-dependencies` of the crate include something that uses `std` apply to
   my project and cause this problem?  Or does it not apply because I have no
   "cargo features" and/or have no external dependencies?
See:
https://tonyarcieri.com/rust-in-2019-security-maturity-stability#bad-interactions-between-code-classprettyprin_2



examples/ directories with hopefully-realistic examples, including a use of
   kul_core from a C program



Make sure all points of fn-call recursion are limited, either inherently or will
   need to add manual limiting, to avoid unexpected stack overflow crashes and
   instead return error(s) that indicate what happened.  Esp. w.r.t. parsing
   input texts, which are often untrusted, where our nest form syntax allows
   very deep nesting that causes recursion in the parsing.

This will be challenging to do well.  Basic numeric limits on nest depth (or
   call recursion) aren't a very good way because stack overflow can still occur
   if the stack happens to already be significantly consumed, which could be the
   case for some users' apps at the points they call our parsing.  Knowing how
   much stack space is left and dynamically limiting based on that seems like
   the only proper way.  Need to research these issues and what Rust can do
   about them.

Maybe ParseIter::incr_nest_depth could be enhanced somehow to check and enforce
   depth/recursion limiting.  It could return a Result so an error can be
   returned to abort before further call recursion overflows, and it could
   delegate the checking to some user- or Rust- or library- provided
   functionality that can dynamically check the remaining stack space properly.



Finish/fix doc-comment links.  Hopefully the `intra_rustdoc_links` feature (RFC
   1946) will become stable soon and can be used to make this task easier and
   better.