feature: Add support for SerializableProgram abstraction to Device interface

[rmshaffer]

Issue #, if available:

Description of changes: The scenario is that an external library like AutoQASM wants to create program objects which can be executed on Braket devices, including local simulators and AWS devices, but also wants the freedom to return (simulated) results in a format that does not necessarily match the Braket schema for gate model task results.

This change adds a minimal abstraction, SerializableProgram, which represents a program that can be serialized to OpenQASM. It adds support for this in the Device class so that these programs can be run on Braket, while also supporting a local simulator which wants to return a GateModelQuantumTaskResult directly rather than being forced to match the schema of GateModelTaskResult.

For example implementations of this abstraction, see:

• https://github.com/amazon-braket/autoqasm/blob/7e4441dd6cc42c1ee01b52d86e1ee7a04fa15b40/src/autoqasm/program/program.py#L121-L154
• https://github.com/amazon-braket/autoqasm/blob/7e4441dd6cc42c1ee01b52d86e1ee7a04fa15b40/src/autoqasm/program/program.py#L227-L261

Testing done: Tests added to verify new code and maintain 100% code coverage.

Merge Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your pull request.

General

• [x] I have read the CONTRIBUTING doc
• [x] I used the commit message format described in CONTRIBUTING
• [x] I have updated any necessary documentation, including READMEs and API docs (if appropriate)

Tests

• [x] I have added tests that prove my fix is effective or that my feature works (if appropriate)
• [x] I have checked that my tests are not configured for a specific region or account (if appropriate)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 100.00%. Comparing base (ec5edaf) to head (677d810).

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #976 +/- ## ========================================= Coverage 100.00% 100.00% ========================================= Files 135 135 Lines 8903 8917 +14 Branches 1998 2002 +4 ========================================= + Hits 8903 8917 +14 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[yitchen-tim]

It adds support for this in the Device class so that these programs can be run on Braket, while also supporting a local simulator which wants to return a GateModelQuantumTaskResult directly rather than being forced to match the schema of GateModelTaskResult.

If the vision is to support any simulator that can execute OpenQASM, do you think it's worth creating a new result class instead of GateModelQuantumTaskResult? Currently, the MCM simulator writes results in the measurements field of GateModelQuantumTaskResult. Although GateModelQuantumTaskResult does not validate the field type, it does have type hint and doc that does not agree with the value written into the measurements field.

[rmshaffer]

If the vision is to support any simulator that can execute OpenQASM, do you think it's worth creating a new result class instead of GateModelQuantumTaskResult? Currently, the MCM simulator writes results in the measurements field of GateModelQuantumTaskResult. Although GateModelQuantumTaskResult does not validate the field type, it does have type hint and doc that does not agree with the value written into the measurements field.

You're right, using the measurements field for arbitrary output values is not really intended. To support arbitrary OpenQASM programs with output variables, eventually we would need a task result object which is more generic than the current GateModelTaskResult and GateModelQuantumTaskResult, both of which assume that the result of a task is a single bitstring. However, doing this correctly would involve defining a new task result schema (in the schemas repo) which I believe is beyond the scope of this PR.

One possible option for now would be to define some kind of generic QuantumTaskResult object which does not have any particular schema. But this feels like it would be a temporary solution and I'd be hesitant to add that now. Curious to get other thoughts on this.