Description

the tldr version is that
there are some issues when Hires prompt (different prompt for hres pass) and Styles is use toughter
the infotext will distinguisher or parsed incorrectly

Current situation

1. Prompt: the final prompt incouding the applyed Styles
2. Hires prompt is used when it's difftent from the first pass prompt
   the Hires prompt in infotext dose NOT includs applyed Styles
3. Styles are applyed to both Prompt and Hires Prompt during image generation
4. When parsing infotext, the Styles are extracted form Prompt only

This causes it feels under certain situations when boath Styles and Hires prompts is used

• if at the time of parseing infotext a Styles that was use in NOT matched by any of the uses defined styles.csv
  the Styles will not be extracted and will be left in Prompt
  but now this meant that this Hires prompt will not have Styles
• if a Styles is applyed into prompt, as it is applyed it is no longer a really a Style and so will not be apply to both prompt and Hires promp
  but when reading infotext, as the style is match in Prompt, the Style will be extracted, now and so on generation the Style will be applyed to boad
• if Infer styles from prompts / infotext_styles is set to ignore, it will not be able to read infotext correctory as hires prompt dose not contain syles

tldr: webui may not be able to retrive the original infotext when Styles and Hires prompt is used

fix solution

1. Hires prompt infotext should have the Styles in it
2. When extraction styles, it should comferm if the same Styles is present in Prompt and Hires prompt
3. for backwards compatibility, it shoul parse the webui version from infotext, if the infotext was genereaed before this PR, this fix 2. will be disable
   if version info is not found behavior would be enabled

after this PR new intotext should not have this issue anymore
when passing old infotext the behavior is not changed as new behavior is disabled

additional information:
hires prompt was introduced about the same time version was added to infotext, so unless the user disable adding version to infotext ro if the version info was removed for some reason, using version to perform the backwards compatibility shuld be good enough

I contemplated on adding an option to disable this behavior but aside version info in missing, even though this may help back what's compatibility I felt that it would cause more issues in the future

minor changes:

1. extra_generation_params["Hires prompt"] in no longer used to set hires prompt init()
2. in create_infotext hires prompt will be written to infotext if it is diffrent to prompt

suggestion

1. as we now currently use the version info in infotext for compatibility, it makes sense to make shared.opts.add_version_to_infotext mandatory
2. assuming that this PR is accepted I would like to imporve create_infotext so that so that it's easier to add "index generation parameters" (such as seed or prompts) in a way that it doesn't require adding additional input arguments
   this would benefit extensions

note: in this PR description I only mentioned prompt and hires prompt, the same logic is also applied to ther negative counterpart.

Checklist:

• I have read contributing wiki page
• I have performed a self-review of my own code
• My code follows the style guidelines
• My code passes tests