Constrained create issue screen doesn't preserve behaviour context id when project is changed

To reproduce:

• Set up a 'Constrained issue create dialog' script fragment.
• Set up a behaviour (mapped to all projects/issue types) whose initialiser code is conditioned on the value of getBehaviourContextId() (i.e. if (behaviourContextId == "foo") ...).
• Go to wherever you put the fragment in the UI and click it.
  • The initialiser code will run.
• While the screen is still open, select a different project from the drop-down.
  • The initialiser code will not run. (To be more precise, the code which is guarded by the conditional won't run.)

(N.B. The other way to see what happens is simply to attach a debugger, put a breakpoint in your initialiser code and just look at the return value of getBehaviourContextId() directly in e.g. the expression calculator.)

It looks like the reason this happens is that when the fragment is clicked, it triggers some JS to store the context id in an invisible <div> immediately above the <form> element on the create screen, which is then referred to later by the behaviours JS. Presumably when the screen gets rebuilt during a project switch, this <div> gets thrown away, and we don't have any code in place to restore it. The counterargument to this is the evidence of SRJSUP-2895, in which it appears to be the case that the context id is sometimes successfully carried through the switch (although bear in mind that in this case it's the issue type that's being changed: maybe this triggers a different kind of screen rebuild?)

All of this is somewhat moot at present because you can't use the constrained creation screen to create an issue in a different project to that which was specified in the fragment's configuration (unless you work around it à la SRJIRA-2011).