Determine & Document how loops will be handled

[NoahGWood]

Due to the pulsed nature of LOQC, it is only possible to create a loop type program by the use of optical delays (physical optical loops) which can be upwards of several meters in order to allow enough time for the switching circuitry to activate, this greatly decreases circuit coherency (this is one of the biggest flaws in LOQC and other optical quantum paradigms).

As of now it looks like we have a few options:

1. Abandon loops altogether
2. Evaluate loops prior to synthesis (no looping controls, a loop will repeat a given block n times). - Much faster/safer
3. Evaluate loops in 'run-time' mode where loops (and delay and control circuitry) is built-in. - Much slower/dangerous
4. Hybrid between 2 & 3 - Evaluate as many loops as possible and only implement run-time loops when necessary - Probably the best option

It is proposed that we pursue the fourth option for loops, but the community is welcome to comment on which they would prefer.

It is also proposed that if we do go with the Hybrid model this feature be documented and additional documentation be written when a 'best practices' guide is created to dissuade the use of loops for this architecture whenever possible.

[pranith7867]

@NoahGWood can i work on this issue