Allow build w/o __GCC_HAVE_SYNC_COMPARE_AND_SWAP_[48]

This commit resolves compilation errors in the generated
clang-upc-lib.h for the case where __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4
and __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 is missing.  Specifically, this
ensures inclusion of the typedefs required for the prototype of the
external __upc_atomic_cas().
Implement __upc_atomic_cas via __atomic_compare_exchange

This should resolve the remainder of issue #27
Propsed fix for item #52 in upc2c's issue tracker

This recurses down the type being initialized to ensure that the
eventual '0' is nested inside the correct number of curly brackets.
This *should* deal with arbitrary nesting of array, struct and union
types (keeping in mind that struct and union are both RecordType).

I say *should* because I have yet to construct the test cases I
need to verify my claim.  In particular, I've not yet attempted
any union types at all (let alone nested).
Remove dead code which was pending investigation

This commit removes an #if0'd block of code I had temporarily retained
until I could investigate further.  The removed code was inserting
"(TYPE)" before the remainder of the output, which techncially made
the output a compound-literal rather than an initilizer-list.

Keep in mind that as implicit initializers, the output from this
function is appearing as an element within the scope of an
initializer-list.  The code was removed initially because I found that
the Portland Group compilers in C99 mode would reject the use of
compound-literals within an initializer-list, but was willing to
accept the new alternative.  Meanwhile gcc-pendantic, icc, suncc, xlc,
opencc and pathcc were (in their C99 modes) all willing to accept both
variants.

My investigation consisted of a carefull reading of sections 6.5.2.5
(Compound Literals) and 6.7.8 (Initialization) of the ISO C99
specification, along with Appendix A (Language syntax summary). I
actually read the widely available "N1256" committee draft).  There
were two "findings":

1) I determined that the current form of the code (generating an
initializer-list) is valid ISO C99.  In fact it is fully consistent
with all of the examples in section 6.7.8, none of which include a
compound-literal.

2) The second finding is that the previous output involving a
compound-literal is ALSO valid ISO C99.  Specifically if you
start in Appendix A at initializer-list and work your way upwards you
will find that any postfix-expression is a valid (singelton)
initializer-list.  One explicitly valid postfix-expression is:
   ( type-name ) { initializer-list }
So, the Portland Group compiler *is* buggy.

On balance I prefer that upc2c generate the most portable code
possbile.  While I dislike making excessive allowances for other
people's bugs, this is a case of choosing between two equally valid
outputs.  So, I would favor the new output (very slightly) based on
the fact that it is acceptible by more compilers.  What tipped the
scale for me is the fact that the new output is valid ANSI C89.  Thus
it should be more widely accepted even by compilers I did not have the
opportunity to test.
One-line fix for crash on bug858a.c
Merge pull request #28 from PHHargrove/issue27

Allow build w/o __GCC_HAVE_SYNC_COMPARE_AND_SWAP_[48]
Handle the case of empty structs w/o crashing
Produce correct output for zero-length arrays
Emit parens around GCCAsmStmt input and output expressions
Check for errors when processing command line arguments.  Fixes upc2c#47.
Fix the expected results.

 - UPC version string should match UPC 1.3 spec
 - We allow pointer to shared to int cast
Merge pull request #33 from PHHargrove/fix-asm-parens

Emit parens around GCCAsmStmt input and output expressions
Fixes typos reported by upc2c issue 59.  Report and fix by PHHargrove.
Merge remote-tracking branch 'PHHargrove/upc2c-issue-52'