feat: add retry metadata to fsm decl

[matt2e]

Changes:

• Extract retries metadata declared for a FSM. The idea is that this will be the default retry policy for each transition, but that is out of scope for this PR.
• Traversing the ast graph now provides a stack of nodes rather than just the current node (so we can derive info based on parent nodes, rather than maintaining that state with special cases)
  • removed currentVerb from parserContext as this special case is no longer needed

Add retries to a FSM like this:

// The payment FSM.
//
//ftl:retry 10 5s 10m
var paymentFSM = ftl.FSM("payment",
	ftl.Start(Created),
	ftl.Start(Paid),
	ftl.Transition(Created, Paid),
	ftl.Transition(Created, Failed),
	ftl.Transition(Paid, Completed),
)

In the schema it looks like this:

fsm payment
   +retry 10 5s 10m
{
   start fsm.created
   start fsm.paid
   transition fsm.created to fsm.paid
   transition fsm.created to fsm.failed
   transition fsm.paid to fsm.completed
}

[alecthomas]

In goast, there is no relationship between ftl.FSM(...) and the comment group, so this PR makes a map of line number to comment group node, which we can then look up when we find the FSM function call.

You should be able to find variable declarations of the FSM type, then get the comments from the variable no?

[alecthomas]

How should retries for FSMs show up in schema?

I like this syntax 👍

[matt2e]

In goast, there is no relationship between ftl.FSM(...) and the comment group, so this PR makes a map of line number to comment group node, which we can then look up when we find the FSM function call.

You should be able to find variable declarations of the FSM type, then get the comments from the variable no?

Ah you're right, the variable declaration holds the documentation.
I've made Visit() provide a stack which makes this a lot easier to do. And it removes the need for parserContext to track activeVerb

[matt2e]

regex did the dirty work here, no RSI was harmed