In that case, there will be a `nil` at the place of the text of the
node in the arg-list.
They have to be explicitly marked as optional, since we currently have
the behaviour of not updating nodes at all if an argnode is missing.

dynamicNode has to return .static_snip instead of .snip

Previously:
InsertNodes trigger an update on input_leave.

This works, but, if updates invalidate nodes that are currently involved
in being jumped over, we'd have to abort and roll back the jump, or do
some other recovery.

To avoid this, update_dependents is done _before_ any jumping is
performed (this is really more elegant now since we can keep track of
which nodes are "above" some insertNode, and then just get all of them
and their dependents (see
node_util.find_node_dependents/collect_dependents))

So, now `ls.jump` does essentially:
* store position of cursor relative to active node
* collect nodes that depend on the text of this node (so, all dependents
  of all parents of this node)
* update them
* try to find an equivalent node (node with the same key, or if a
  restoreNode is present, the exact same node :D) and perform the jump
  from it
* if an equivalent node could not be found, just enter the first
  dynamicNode (starting from the previously active node) and enter it

Obviously, this only really works well if an equivalent of the current
node can be found in the new generated nodes.

Similarly, active_update_dependents

put_initial is not called on it, but since it's always visible we can
set it when initializing.

This is important to prevent an infinite loop when a snippet is
remove_from_jumplist'd in node_util.snippettree_find_undamaged_node: if
child_snippets is not modified, we just continue to remove it (or call
:r_f_j but immediately nop because the snippet is not visible).

Has to happen because we modified text.
I don't like using vim.schedule here, but it seems like this is the
only way of getting the desired behaviour into all possible ways of
expanding snippets (direct snip_expand is used by cmp_luasnip, so can't
just handle `expand` and its variants in init.lua (or, we could do so
and submit a PR to cmp_luasnip, but let's wait with that until this
actually becomes problematic, which I don't think it will)).

This includes `put_initial`, so a restoreNode will now store snippets
expanded inside of it!! (which is really cool :D)

This allows us to duplicate snippets within argnodes into the
dynamicNode.

If store is triggered manually (for example in dynamicNode:update), it
should also be performed for the entire snippetTree!

This enables restoring the dynamicNode content in snippetStrings.

exit is also called when a snippet should be deleted due to invalid
extmarks, if we do something like store in there, we have to always
check extmarks.

For now, leave a pcall in get_snippetstring, get_text behaved the same.
But log errors!

weirdly that one test breaks, and only on nvim0.7.. I don't think it's
an actual bug in luasnip. so just skipping that test for now.

This should simplify applying string-operations.
Also don't store the string of a snippet, just reconstruct it when
needed.
We do this because it is much easier than figuring out exactly how
indent or expand affect a snippet (indentSnippetNode can affect them, so
keeping them in sync manually seems infeasible.)

set parent_node in insert_into_jumplist, and rename reown to copy (so it
can be used more generally and not just in the context of some
insertNode receiving the snippetString as static_text).

lower, upper, and ..

If possible, snippets are preserved, and if they can't be preserved they
will gracefully degrade to raw text.

:store only really makes sense for nodes where we can't store the text
as its' being generated, which is exclusively insertNode.

Whenever update_dependents is called by luasnip, we can be sure that
it's safe to call currently.

if we can restore a previously generated snippet, we should do so to not
revert user input.

safer, update_dependents could remove the entire choiceNode, not good!

And store generated snippet in .snip, not .snip_stored, which is not
reached by subtree_do, which we would like to have apply to the stored
snippet.

Previously, we used a metatable to refer to the choiceNode for some keys
that are required, which are only .parent and .pos.

This may improve the accuracy of docstrings generated on an expanded
snippet.

Otherwise the jump_into from change_choice may complete after the
cursor-movement due to the subsequent update.

Much more appropriate, also get_current_choices will work even if some
insertNode is not visible.

* handle column-shifted begin-position (only shift cursor-column if it
  stays in the same line)
* correctly enqueue cursor-movement via feedkeys.

Code is essentially the same thing.
Also allow passing the current cursor to ls.set/change_choice, which is
useful for extras.select_choice, where the cursor-state is "destroyed"
due to vim.input, and should be saved before that is even opened.

metadata can store eg. when a snippetString was created, marks are a bit
like extmarks, they can mark a position in a snippetString and are
shifted by text-insertions.

Cache `static_text` (for insertNodes) and don't query it anew while
luasnip is operating. This is valid under the assumption that all
changes to the buffer are due to luasnip while an api-function (jump,
expand, etc.) is running.

This is enabled by session.luasnip_changedtick
which is set as soon as an api-function is called, and prevents
re-fetching snippetStrings from the buffer (which in turn allows us to
set the cursor-position once, and then have it propagate through all
updates that are triggered subsequently).

This commit also replaces no_region_check_wrap with api_do, which is
more general (handles both jump_active, which prevents recursive
api-calls and luasnip_changedtick)

See extensive comment in commit.

By inserting the stored snip into the buffer, `get_args` during
`update_restore` can find the argnode inside the snippet.

If we don't do this, the content of a choiceNode may not be restored
correctly.
(or, it will be restored correctly, but it won't be what the user saw
before they called change/set/select_choice, which seems suboptimal).