Bug fix: Convert layout to layout_x and layout_y in FlorisInterface.reinitalize

[RHammond2]

Feature or improvement description
This PR modifies FlorisInterface.reinitialize() to transition the layout parameter to be layout_x and layout_y and all reliant functionality. This resembles the behavior within FLORIS itself, and clears up the confusion surrounding what the correct dimensions of layout should be and accidental truncating of a farm's layout.

Related issue, if one exists
#413

Impacted areas of the software
floris.tools.floris_interface.FlorisInterface
floris.tools.optimization.pyoptparse.layout.Layout
floris.tools.uncertainty_interface.UncertaintyInterface

Additional supporting information
n/a

Test results, if applicable
All tests pass, though there aren't any tests for this class as it stands.

[paulf81]

I agree with this change, thank you @RHammond2

My only thought, to not brake legacy code, what do you and @rafmudaf and @bayc think about allowing still the layout to be passed in (and a small block that parses it back to layout_x and layout_y in that case)? We can add a deprecation warning that we'll phase it out completely in 3.3 or something?

[rafmudaf]

With layout available again, this doesn't truly fix #413, right?

[RHammond2]

@rafmudaf, I think that implementing deprecation warning and encouraging the use of layout_x and layout_y in place of layout, in addition to changing all the examples so they rely on the use of layout_x and layout_y, should help transition users into not using the layout parameter. I'm happy to defer to you if you think we should implement the change immediately, but realizing that this would break users' code, giving a minor release in between breakage seemed kinder.

[paulf81]

You're right @rafmudaf in theory that issue will not be resolved until we cease allowing layout, but I agree having a minor release with a deprecation warning seems kinder

[rafmudaf]

That sounds good to me, as well. In that case, @RHammond2 I've removed the "closes" word in your original post so that GitHub doesn't automatically close that issue.

[RHammond2]

That works for me to not close this. Should we tag this with a new v3.3 tag to remind ourselves of it?

[rafmudaf]

Yes very good idea!

[paulf81]

Agree, starting to flag some things for v3.3 sounds great!