keep track of the subroutine definition order

[jcjaskula-aws]

The order of the subroutine definitions was based on their call order. We now update a list of function name at decorator call.
Only subroutines that have been called in the program will be added to prog.subroutines. The subroutines are then added to the program at the final serialization step in order given by prog._subroutine_definition_order.

Added a unit test.

[braised-babbage]

Would it be possible to preserve the ordering of all declarations, regardless of type? For example, in OpenQASM a subroutine definition can refer to a global const declaration, but OpenQASM does require the const declaration to precede the subroutine definition. As a further extension to this mechanism, for OpenPulse we may wish to allow subroutines to refer to global definitions even if not const. It's also possible for a subroutine to have a gate application in its body, assuming the defcal precedes the subroutine definition. As it stands right now, the reordering (where subroutine definitions precede everything else) can make it hard to control the output.

[jcjaskula-aws]

Would it be possible to preserve the ordering of all declarations, regardless of type?

Some variables are automatic declared at serialization for convenience. This might make strict ordering more difficult. Users could always force the declaration if they want to have it somewhere precisely.
That said subroutines are currently declared at the top by construction, but we might add a flag to the decorator to change this behavior.

[PhilReinhold]

Looks good, just a few suggestions

[PhilReinhold]

Very nice, I like the new changes! It is much more consistent in how the declaration gets handled.