Support Control Flow type Refinements for "break" and "continue" statements

[AmberGraceSoftware]

Fixes: #913

This PR adds support for type refinements around guard clauses that use break and continue statements inside a loop, similar to how guard clauses with return is supported.

I had some free time today, so I figure I'd give a shot at a naïve fix for this at the very least.

---

Resulting Change:

Luau now supports type refinements within loops where a continue or break guard clause was used.
For example:

for _, object in objects :: {{value: string?}} do
    if not object.value then
        continue
    end
    local x: string = object.value -- OK; Used to emit "Type 'string?' could not be converted into 'string'"
end

---

ControlFlow enum

I added some bit flags to the ControlFlow enum, as it looks like was defined in an incomplete/imprecise way. There are inline comments in the ControlFlow.h file that you are free to remove; I added them for the sake of documenting my reasoning.

The changes to the ControlFlow enum make it more explicit that edge cases of mixed exits need to be considered in future additions to control flow analysis.

A "MixedExit" control flow looks something like this, where a conditional always has an exit, but this exit might be to the nearest loop scope, or to the nearest function scope:

if condition then
    break
else
    return
end

A "MixedFunctionExit" is specifically a mixed exit that always exits the nearest function scope:

if condition then
    return
else
    error("...")
end

A "MixedLoopExit" is specifically a mixed exit that always exits the nearest loop scope:

if condition then
    break
else
    continue
end

It looks like this proliferation was what the previous author of this type refinement code was getting at, but didn't completely represent. For example, calling TypeInfer::check() on an if statement would always return ControlFlow::Return for any mixed function return, even if that mixed return might actually include an exception rather than a return.

Probably makes no difference either way, but I figured specificity is better than ambiguity in this instance.

[alexmccord]

Sorry for the extremely delayed review! I have some changes that I want to see first before I can merge this in.

[alexmccord]

Ended up pushing the changes I wanted to see because it's been sitting in limbo for too long and I didn't want it to wait longer.

[alexmccord]

Thanks!