Issue title: Folding still slow sometimes during insert mode
 Issue body: Slow inserting due to folding has improved a lot since #77 has been fixed.

However, there is still an issue: Some other plugins (e.g. ultisnips) have insert mode bindings which seem to shortly leave insert mode to do things. E.g. the <tab> binding triggers expansion of a snippet. This is still slowed down, since the folding is recomputed as insert mode is left.

How can it be fixed? Maybe we can (somehow) add a delay before the foldmethod is changed (a simple sleep won't cut it, the change needs to be done in the background)? Alternatively, the foldmethod could be sped up?

 Comments: 
 Comment 0: Maybe this could work:

`autocmd InsertLeave *.tex augroup FoldMeth | autocmd FoldMeth CursorHold * setlocal foldmethod=expr | autocmd! FoldMeth CursorHold`

This basically delays setting the fold method to the next CursorHold event (which happens after 4s of idle cursor) and then deletes the CursorHold hook. 

Downside is that the user needs to keep idle for 4 seconds for the folding to be pjones@example.org.

Also, the code needs to be optimized. Currently, a new CursorHold hook is inserted whenever insert mode is left. It would be cleaner to remove the InsertLeave autocmd and only re-add it from the CursorHold autocmd.

It feels dirty, altogehter, but works. What do you think?

 Comment 1: I agree the idea seems to work, but I also agree it feels dirty.

I'm trying to see if we could use a cache instead. If that does not work, then I think your solution might be ok.

Btw: Have you tried Snipmate? I have no problems with folding and Snipmate. I have not tried ultisnip, so if you have tried both, I would be happy to hear why you use ultisnip instead. :)

 Comment 2: Hi,

I've created a function that uses cache, and it seems to work reasonably well. There are short delays, but nothing as severe as the "original" version. Could I send you the function on email, and could you test it? I don't want to push it until we're sure it is an improvement.

 Comment 3: Hi,

I just pushed a development branch called `cached-folding`. Please test it and see what you think. Notice I still use the FastFold autocommands. Please test also without that autocommand group. At least with me this new cached folding is faster than the old one when pasting in insert mode.

 Comment 4: I just tried it out, I see no difference (i.e. no speed up). However, I did take a quick look at the code. It seems like for lines that retain the fold level of the previous line (line 180-184 of folding.vim), there is never a cache hit. This may be the majority of the lines (but I haven't really dug into the previous lines of Latexbox_FoldLevel() to see whether they are covered elsewhere).

 Comment 5: I don't know how vim variables are initialized, but is the initialization in line 129 done each time the function is called? That would negate any benefit of the cache I assume.

 Comment 6: I think the only thing saved is that it prevents the recursive behaviour of the original version. Thus it should be faster than the original (and it is with me), but I agree it is still not fast enough. In other words, it may be wrong to use the term "cache". :\

One of the problems with improving this idea is that I don't really know when the fold function is called. It seems to me that it is called for every line of the file, every time the folds are refreshed. Perhaps that is wrong, and perhaps it is only called on a given line if the line has changed.

Another improvement could be to also save every line in the cache. This would enable us to check if the line has changed, and if not, then we can return the old fold level. However, things get complicated, since the fold level of one line almost always depends on the fold level of the previous line.

 Comment 7: Hmm. I am also not sure when the fold function is called, but I assume (from the slow down) it is quite often (i.e. at least once per line). I added some echom to the function, it does seem every line is visited once after an update (i.e. leaving insert mode). This is congruent with the help:

`Note: Since the expression has to be evaluated for every line, this fold method can be very slow!`

For each line that does not change the folding level (normal text), there are at least 8 pattern matches I counted (assuming all fold features are enabled). This is probably what's costly. To improve this, we should have a (simple) check at the beginning of the function whether we have a 'plain text' line. Something like this (added at line 131) yielded acceptable speed:

`if line[0] != '\'
        let b:LatexBox_FoldCache[a:lnum] = s:GetFoldLevel(a:lnum-1)
        "echom "cache miss for line ".a:lnum. " is ". b:LatexBox_FoldCache[a:lnum] 
        return b:LatexBox_FoldCache[a:lnum]
    endif`

The test only checks the first character, we should make it a bit more sophisticated. It doesn't need to be perfect in the sense that it may yield false negatives (which would be caught further down), but must not generate false positives (which would screw up the folding). The current test probably does yield false positives (although folding looked ok in my file). Maybe you can come up with something better.

Note that the fold function still will be called once per line and these function calls already cause some overhead. The syntax fold method (used by vim-latex) could be faster here.

The help also hints at avoiding the use of '=', 'a', and 's' return values, as these may cause recursive searches until an independent fold level can be found in the lines above the current one. But I don't know if you are still using those.

Regarding caching, it seems like a good idea to remember previously calculated fold levels. However, I am not sure how we know when to invalidate the previously computed (cached) fold level. When a line of text is changed (is there a hook for this?), all fold levels above this changed line should remain valid, only those below need to be invalidated... But it could be complicated in the end and maybe not necessary.

OK, I will go to bed now :)

 Comment 8: You are right, the foldlevel function is called on each line of the file, every single time the folding is updated (which is often). Thus we should try to make it return as quickly as possible in most cases.

I think my "caching" idea does work a little bit, though, since it removes the "=", "a", and "s" return values. These are, if I understand correctly, recursive, and thus very expensive. The cache variable I introduced should simpliy "=", "a", and "s" to simple look-up-tables, which is much less expensive.

I'll look at this more tomorrow, but I think your idea of having a check in the beginning for "normal" lines is good, since there are O(n) "normal" lines in a file, and only O(1) "special" lines. I'll try it tomorrow and make a version that should not yield false positives, and push it to the devel branch (cached-folding).

Btw: vim-latex, or latexsuite, does not use syntax folding. They use manual folding with a very fancy plugin on top, which works similar to syntax folding but not quite. I guess this makes much more effective, but at the same time the plugin is kind of bloated in my opinion.

{'source': 'GithubIssues', 'repo_name_with_owner': 'LaTeX-Box-Team/LaTeX-Box', 'issue_id': 13962495, 'repo_stars': 395.0}