Add support and proper relocation of GCC loop pragmas [GH #174]

[mborland]

In #165 we found that GCC loop pragmas such as #pragma GCC unroll 4 were relocated to the top of the function, causing a compilation error from the emitted C. This PR adds support for GCC's three loop pragmas: unroll, ivdep, and novector, and ensures that they stay immediately before the loop, rather than being relocated. Previous tests with unrecognized or unhandled loop pragmas have been updated to reflect this new support.

Closes: #174

[wchilders-nvidia]

So one question more than anything else is, what's the rationale for gcc_loop_pragma instead of integrating into gcc_pragma (which handles dispatch for all(?) "GCC" pragmas)?

[mborland]

So one question more than anything else is, what's the rationale for gcc_loop_pragma instead of integrating into gcc_pragma (which handles dispatch for all(?) "GCC" pragmas)?

Good question. Prior to this PR we know that the gcc_pragma path was handling these three loop pragmas, but with incorrect behavior. I thought it made more sense to handle these pragmas separately rather than a special case of gcc_pragma because there were multiple such cases that each needed the same special handling. ivdep is a fairly recent addition, and now this would provide extensible handling if other loop pragmas are added in the future by adding the new name to loop_pragma_names.

[daveedvdv-nvidia]

Thanks for taking this on!
I added some comments. Many are just formatting nits.
The significant one is that I think these changes make the #pragma "recognized", and so we should no longer issue a diagnostic for it.

[mborland]

@daveedvdv-nvidia and @wchilders-nvidia I believe have addressed all of your comments.

[mborland]

I have re-run the CI since I think this was affected by the GitHub actions outage yesterday. Everything is back to green.