Replace VLA for MSVC compatibility

[projectitis]

• Replaced VLA with alternative
• Now able to compile successfully using Visual Studio

[luigi-rosso]

@mikerreed @chris-rive we were discussing this a while ago

@chris-rive maybe you can take a look at whether there's a configuration flag or something that can enable variable-length arrays in MSBuild? This has bitten us before and it kind of sucks to have to resort to allocating them on the heap every time (Mike mentioned Skia has a cool abstraction that allocated on the stack and grows to the heap only if necessary that maybe we should adopt).

[projectitis]

MSVC has _alloca and _malloca for stack allocation. I'm guessing that's what the abstraction layer would resort to.

[csmartdalton]

whether there's a configuration flag or something that can enable variable-length arrays in MSBuild?

If you install Visual Studio with Clang tools, you can use LLVM as your platform toolset instead of MSVC. I wonder if this would allow us to use variable length arrays and other Clang features?

Using GN on Skia we were able to build entirely with Ninja/Clang, and just set up a custom build command for working inside Visual Studio. I would love it if we could do that here as well. Clang has much better support for SIMD, whether that's SSE, NEON, or WASM, so I would really push for us to drop MSVC support and instead focus on figuring out how to use Clang everywhere.

Skia has a cool abstraction that allocated on the stack and grows to the heap only if necessary that maybe we should adopt

I think we could accomplish the same thing using a custom allocator with std::vector, which would be more "standard" and future proof, I believe. I like the concept and think we will probably want it, even if we also get in support for variable length arrays.

[csmartdalton]

Is there a limit on how long "count" can be? If not we probably do want a wrapper that uses stack storage up to a certain threshold, then falls back on heap storage.

[projectitis]

Clang has much better support for SIMD, whether that's SSE, NEON, or WASM, so I would really push for us to drop MSVC support and instead focus on figuring out how to use Clang everywhere.

I can confirm that the codebase compiles out-of-the-box with clang-cl using visual studio. The command line options work, and VLAs are fine. There are about a million warnings, but I get a rive.lib at the end of it.
EDIT: I tell a lie. The command line options -fno-exceptions and -fno-rtti are still ignored by clang-cl (-Wunknown-argument). But I still get a lib.

I ran premake5 vs2019 and then loaded the solution file in visual studio and made a few changes to the options, including selecting clang-cl as the toolset.

The warnings are a symptom of the -Wall flag. I've found out it is recommended to use -W4 instead with clang otherwise every other line gives you a "Not compatible with c++98" warning :(

So if you are thinking of ditching MSVC support, I'm happy to close this PR? Otherwise I can suggest an alternative that uses _malloca (docs). This function attempts to allocate via stack, and if not possible, uses heap instead.

[projectitis]

@luigi-rosso Is the 'official' ( 😁 ) support on windows for clang-cl and not MSVC?
If so, I will close this PR.