Allow for user-specified input/output delay

For pipelined designs it is sometimes desirable to allow inputs to flow through some amount of combinational logic before being flopped. The amount of delay allowed through this logic would be user specified. A typical setting might be 50% of the clock period. Symmetrically, outputs could support this feature as well.

A simple, but imprecise way of handling this is to give receive nodes some amount of delay. Problems with this approach (from @hongted ):

> Couple of limitations are
> 1) it doesn't exactly place an additional delay on the input port -- but rather the receive op possibly resulting in double counting if those receive ops are chained via tokens>
> 2) even if receive ops aren't chained by tokens, one receive op could feed the predicate of the other -- again resulting in double counting.

My (@meheff ) response:

> (1) could be resolved by fanning out tokens to parallel receives rather than serializing them. This would naturally be what we would do if a token dependency implies separate cycles for the dependent ops.
>
> (2) for this we'd need something more sophisticated. Essentially what we want is the receive to be scheduled no earlier than N ps in the cycle. This could be enforced via a special rule. Seems like it could work but I don't know all the ramifications of this.

For output delay, I think just given sends the desired delay should work because there can be no data path between sends. I.e, (2) is not a problem.