When parsing with a range, languagetree looks up injections and adds
them if needed. This explicitly invalidates parser, making `is_valid`
report `false` both when including and excluding children.

This is an attempt to describe desired behaviour of `is_valid` in tests,
with what ended up being a single line change to satisfy them.

Problem:  Visual highlight is inconsistent on a folded line with
          treesitter foldtext.
Solution: Don't added Folded highlight as it is already in background.

This is incorrect in the following scenario:
1. The language tree is Lua > Vim > Lua.
2. An edit simultaneously wipes out the `_regions` of all nodes, while
   taking the Vim injection off-screen.
3. The Vim injection is not re-parsed, so the child Lua `_regions` is
   still `nil`.
4. The child Lua is assumed, incorrectly, to occupy the whole document.
5. This causes the injections to be parsed again, resulting in Lua > Vim
   > Lua > Vim.
6. Now, by the same process, Vim ends up with its range assumed over the
   whole document. Now the parse is broken and results in broken
   highlighting and poor performance.

It should be fine to instead treat an unparsed node as occupying
nothing (i.e. effectively non-existent). Since, either:
- The parent was just parsed, hence defining `_regions`
- The parent was not just parsed, in which case this node doesn't need
  to be parsed either.

Also, the name `has_regions` is confusing; it seems to simply
mean the opposite of "root" or "full_document". However, this PR does
not touch it.

`resolve_lang` is applied to `@injection.language` when it's supplied as a
capture:

https://github.com/neovim/neovim/blob/f5953edbac14febce9d4f8a3c35bdec1eae26fbe/runtime/lua/vim/treesitter/languagetree.lua#L766-L768

If we want to support `metadata['injection.language']` (as per #22518 and
[tree-sitter upstream](https://tree-sitter.github.io/tree-sitter/syntax-highlighting#language-injection))
then the behavior should be consistent.

Fixes: nvim-treesitter/nvim-treesitter#4918

Unfortunately the gc=false objects can refer to a dangling tree if the
gc=true tree was freed first. This reuses the same tree object as the
node itself is keeping alive via the uservalue of the node userdata.
(wrapped in a table due to lua 5.1 restrictions)

Problem: `push_tree`, every time its called for the same TSTree with
`do_copy=false` argument, creates a new userdata for it. Each userdata,
when garbage collected, frees the same TSTree C object.

Solution: Add flag to userdata, which indicates, should C object,
which userdata points to, be freed, when userdata is garbage collected.

Co-authored-by: ObserverOfTime <chronobserver@disroot.org>