Factor logic for upc_{notify,wait,barrier}

This commit factors the common logic for constructing the arguments to
the upcr_{notify,wait,barrier}() calls from the optional ID expression.

This is in preparation for fixing issue #42 by inserting casts into
the first argument.  However, this commit does *not* yet change the
upc2c output.
First working solution to issue #42

This commit adds either one or two casts to the first argument to
upcr_{barrier,notify,wait}().  Examples:
  issue64.trans.c:        upcr_barrier((int)9, 0);
  issue64.trans.c:        upcr_barrier((int)10.1234, 0);
  issue64a.trans.c:       upcr_barrier((int)(long)&x, 0);

For the case of a pointer type the expression is first cast to the
target-specific intptr_t (returned by ASTContext::getIntptrType(), and
thus not dependent on stdint.h), to avoid warnings such as gcc's
"cast from pointer to integer of different size".

Currently a "(int)" cast is prepended to *all* expressions (making for
two casts in the case of a pointer type).  However, my intention is to
supress this cast for the common case that the expression already has
type "int".  If implemented, that will simplify the first example to:
  issue64.trans.c:        upcr_barrier(9, 0);
Final barrier id casting logic.

This commit follow up on the stated intent in my previous commit to
omit the "(int)" cast when the expression already has integer type.

I believe this to be the final commit to fix issue #44.
Modify barrier ID logic to use ImplicitCastExpr

This commit reimplements the logic for constructing explicit casts of
the barrier/notify/wait ID.  The logic now uses the ImplicitCastExpr
supplied by clangupc, if any, to decide which casts(s) to insert.

The net (non-comment) source line count is unchanged.
Merge remote-tracking branch 'PHHargrove/issue42'