Recursively expand defcals

[notmgsk]

This PR does two things:

• Recursively expand calibrations, meaning that if a calibration expansion introduces new instructions that have an associated calibration then those instructions will also be expanded (and so on).

• Extends the grammar to permit "formal" arguments to Gate outside of DEFCIRCUIT. This is required because the above change (calibration expansion) is motivated by calibration bodies possibly including gates, and since a calibration can be specified on a qubit variable (e.g. q rather than 0) then the body of the calibration needs to support qubit variables. Previously this was only allowed within a circuit definition, but to make life simpler, it is now possible anywhere a gate is permitted.

[kalzoo]

Thanks! As per our chat, just a couple tweaks:

1. Regenerate with ANTLR 4.8
2. account for and guard on expansion recursion depth. Use a module constant for maximum depth probably

[notmgsk]

Thanks! As per our chat, just a couple tweaks:

1. Regenerate with ANTLR 4.8

Done.

2. account for and guard on expansion recursion depth. Use a module constant for maximum depth probably

Also done, though by a different method. Instead of testing that calibration isn't going too deep, I test that there's no cycle in the calibrations which I think is the more likely issue (i.e. user erroneously supplies a bad DEFCAL). If the user supplies enough (acyclic) calibrations that cause a memory error or w/e, then that's on them.

[notmgsk]

There's a strange build error happening on travis-ci. Looks like test_invalid_protocol is hanging. Not sure why (travis-ci doesn't interrupt it and provide a backtrace), but it doesn't fail locally.

[kalzoo]

Should the grammar rely on the submodule now?

[kalzoo]

Is there a more-expressive error class to use? Is it worth adding a CalibrationError for this and other errors in calibration?

[notmgsk]

I have defined that exception class. There already exists a CalibrationDoesntMatch class, which now has CalibrationError as its parent. Should we define a new child class CyclicalCalibrationError? or is that going too far?

[kalzoo]

would prefer separate or parametrized test cases for these independent programs, i.e.

@pytest.mark.parametrize('program_text', ('DEFCAL RZ(%theta) q:\n\tRZ(%theta) q', ...))
def test_program_calibrate_cyclic_error(program_text):
    ...

[notmgsk]

Restored the grammar symlink. Must've gotten lost in a rebase.