Decoration references

[crossrulz]

As part of the initialization, two references are found to decorations based on tab pages. @dnattinger recently put this nugget in the LabVIEW Discord:
"I typically create the free label, programmatically figure out its UID, then use [LabVIEW 20xx]\vi.lib\VIServer\UID to GObject Reference.vi wherever I need to programmatically modify the label. The UID of a GObject never changes."

We could do something similar for these two decorations we currently do a more fragile lookup for.

[j-medland]

Sounds good - would you want to do it as a self contained PR or will you roll it in to some other refactoring?

[crossrulz]

After my last run, I'm thinking it would be best to keep the PRs to a single refactoring effort, instead of bundling 3 or 4 like I did with my last one. So I say we just go for it with this one.

[crossrulz]

I decided to walk this one back. I have included it with another one of my refactor efforts which I am almost ready to start a discussion on. This was just such a small and simple update that it did not hurt to include it.

[crossrulz]

I did some coding on this and it does work and it is cleaner. But considering both of these decorations are for showing some loading process is happening, I can't help but think these decorations and their respective buttons should be replaced with an XControl or QControl.

In summary, if we want a quick improvement, using the UID lookup is good. In the long term, we need to explore a more modular approach to how these controls are handled.

[dnattinger]

I advise against using XControls in shipping LabVIEW features due to their innate fragility.

I advise against using QControls in shipping LabVIEW features since QControls currently don't ship with LabVIEW.

[crossrulz]

NOTE: I incorporated this idea with the code I am submitting for #232

[crossrulz]

Apparently the UID values change when built into a PPL. I will make an issue to get this corrected by going back to the old way of getting the references.