Add language specification for finally clause

[zerbina]

Summary

This is an attempt at expanding the specification with tests for everything finally related. It's not in a mergeable state yet, but I thought that it might be useful already.

---

The additions to t06_procedure_calls.nim are more or less structured, while t07_finally.nim is currently more of a dumping ground for various test cases than anything else.

To-do:

• add more tests for interactions between finally and both {.inline.} and {.closure.} iterators
• add documentation
• re-organize test cases
• file issues for test cases that fail / put them into separate files with "knownIssue" markings
• there are still missing cases
• it might make sense to add some kind of mini-DSL via macros, in order to write the test cases in a way that makes them easier to comprehend and modify. They're mostly just copy-and-pasted right now.
• a macro or script that auto-generates lots of different permutations might also be a good idea

[haxscramper]

Per discussion in #main - the closest we got to the "everyone sort of agrees it is the way things should be" is (mostly per @alaviss, and I think I can probably agree to it as well).

• If try body exit normally and finally exit for reason R, the block exit for reason R
• If try body exit for reason S and finally exit normally, the block exit for reason S
• If try body exit abruptly for reason S and finally exit abruptly for reason R
  • If S is an unhandled exception and R is not an unhandled exception, the block exit for reason S
  • If S and R are unhandled exceptions, R is chained to S and the block exit for reason R -- R is chained to S (S will be the new toplevel exception in chain)
  • Otherwise, the block exit for reason R and S is discarded

This would allow avoiding dropping exceptions while mostly maintaining the "finally takes priority" behavior that we have now.

NOTE: it is just a tl;dr to keep the context in place - the PR is perfectly fine as it is now, I think.

[haxscramper]

Per current behavior - yield should take priority, like any other 'jump' in finally.
Per recent discussion on how things should be implemented later on - raise should take priority.

[haxscramper]

I think I can work on this later on, after #476 and #135 are merged and general test cleanup is complete.

[zerbina]

Sure, feel free to take this over. I believe the to-do list is still up-to-date.