[BUGFIX] Process in-element in compiler not parser

[gitKrystan]

This fixes the issue described in DockYard/ember-maybe-in-element#25 (comment)

tl;dr If an AST transform introduces the element, it doesn't go through the parser, so it's missing the required guid and insertBefore normalization. This commit moves the processing to a later stage to avoid this issue.

[rwjblue]

This was not used?

[chancancode]

Nope, it was dead code. Unless it’s some kind of public API but then since the entire codebase doesn’t do anything with it I don’t know what that would do either.

[rwjblue]

I don't fully understand why we are resetting this counter for each program. I would have assumed that it was important that the guid we used was unique across each template (or is it needing to be more globally unique?), but resetting in startProgram here will lead to the same template reusing the same cursorCount (and therefore this.cursor() not being unique across the template).

D'oh! I just realized (after digging more into the code) that startProgram here is super misleading. It really should have been renamed to startTemplate when we split the usages of Program AST nodes into Template and Block.

I do still wonder what level of uniqueness we are looking for with the guid, but that is somewhat unrelated.

[rwjblue]

Somewhat ironically, the original code did suffer from the problem I described since it is operating on the Handlebars.Program (which is definitely emitted for each branch of a block).

See this AST Explorer showing that multiple Program nodes would have been seen in the HandlebarsNodeVisitors and therefore the same cursor would be reused within a template like

{{#if foo}}
  {{#in-element this.el}}{{/in-element}}
{{else}}
  {{#in-element this.el}}{{/in-element}}
{{/if}}

[rwjblue]

Thank you @gitKrystan!