Add indentationRules to lua

[rinqu-eu]

No description provided.

[mention-bot]

@rinqu-eu, thanks for your PR! By analyzing the history of the files in this pull request, we identified @egamma to be a potential reviewer.

[Zee1234]

So, Rinqu and I were discussing this, and it came up that a pull request should be made. I kinda thought Rinqu would add some context, but oh well, I'll add it.

This is a PR for the same thing as #31696, but we examined it and considered it inferior to this PR. I don't know git all that well, so I don't know if there's an easy way to show differences between the PRs, so I'll just put them in here.

#31969 :

"increaseIndentPattern": "^\\s*((function|else|elseif|for|if|until|while)|(.*\\sdo\\b))\\b[^\\{;]*$",
"decreaseIndentPattern": "^\\s*((end|else|elseif)|[}\\]]\b)"

#34303 :

"increaseIndentPattern": "((\\b(else|function|then|do|repeat)\\b((?!\\b(end|until)\\b).)*)|(\\{\\s*))$",
"decreaseIndentPattern": "^\\s*((\\b(elseif|else|end|until)\\b)|(\\})|(\\)))"

Henceforth, "first pr" and "original pr" will refer to #31696 and "current pr" will refer to #34303.

The original PR increases indent on elseif, for, if, until, and while, whereas the current PR increases on then, do, and repeat, in addition to the keywords they agree on. Note that every if and elseif is followed by a then in Lua. Every for and while is followed by a do. until is actually a closing block in Lua, corresponding to the repeat statement, so increasing indent on until rather than repeat is nonsensical.

Another benefit to this format is it allows this coding style:

if x
then
  -- code
elseif y
then
  -- code
end

While I cannot speak of the popularity of the format, it still seems better to support it, as opposed to

if x
  then
  -- code
elseif y
  then
  -- code
end

The current PR also explicitly allows one liners ( if x then y() end ) by not indenting lines ending in end, though i do believe the original PR has this functionality as well.

Proper support for the

repeat
  -- code
until truthy

structure is important as well, which the previous PR had improperly implemented.

These reasons are why we consider #34303 to be superior to #31696.

[Stanzilla]

Not sure why the macOS build failed but looks unrelated?

[Zee1234]

Could be unrelated, could also be some RegEx trickery. I'm not honestly sure, and I spent a little bit trying to figure out where TextSearch tests were, but was unable to find them.

[alexdima]

I will first merge #31696 and then this one to also give credit to @jep-a , which work you've built upon.

I am not familiar with lua, so if you don't mind I will ping both of you for help (@rinqu-eu and @Zee1234) if issues come up. Hope you won't mind! :)

[alexdima]

fyi @rebornix

[alexdima]

@rinqu-eu @Zee1234 Thank you for your contribution!