Run grpc code generation in a private application context

[jasonmreding]

Description

Run grpc code generation in a private application context that is closed after each run of the generator. This helps eliminate library/class leaks in the tools menu context which would otherwise require restarting LV to get rid of. It also makes it easier to test from source since the generator will no longer load template libraries into the source project while generating. Otherwise, LV tends to never unload libraries once loaded which often results in name collisions when running the generator multiple times on the same proto file. By loading everything into a private context, we avoid this since it acts like a project where everything gets unloaded from memory when the context is closed at the end.

Implementation

For the most part this involved:

• Creating private application context at start of Main.vi and closing it before going idle
• Deleting application context terminals from existing VIs where it wasn't needed or didn't matter
• Adding application context terminals to connector panes of VIs where it is now needed and couldn't otherwise be extracted. In most cases, I was able to just retrieve the proper app context from an existing VI/library reference using Owning App property from the property node. I audited all usages of Open VI Reference and New VI nodes to ensure they all now use the appropriate app context and not just the "default" context.

In addition, I also:

• Fixed a few icons for correctness / readability as I noticed them.
• Refactored some duplicated code into a common sub VI. Otherwise, I would have had to make the same app context change to N cases of a case structure.
• Fixed and deleted work around for issue where sometimes we were getting error code 1 (mgArgErr) when trying to invoke the Delete method on a project item. This primarily happened when we try to cleanup template VIs that are no longer needed at the end of generation. This would typically manifest itself when generating both client and server at the same time or generating code for multiple proto files at the same time. I ultimately fixed this by invoking ForceDelete rather than Delete. I didn't fully debug the details of this. However, I believe what was happening is that the delete was removing the item from the library but wasn't actually removing/unloading the VI from memory. This then changed the qualified name of the VI since it is no longer part of the library. When doing the same thing on the second library, this would then create a name collision since both VIs have the same name when no longer qualified by a library. Calling ForceDelete works around this since it ignores the resulting name conflict. I also fixed some of the delete code that was only removing from the library and not deleting from disk.
• Cleaned up memory leak as described by Urgent: Memory is full #339

Testing

Manually tested generation of both the client and the server using proto APIs that included nested messages, enums, and oneof fields. Tested both Win32 and Win64 using LV 2019 and LV 2024.

[dixonjoel]

Approved with a couple suggestions / questions.