Fixes #2558. MenuBar positions wrong in some situations.

[BDisp]

Fixes #2558 - Application.Top added by the Application.Init must always be added to the toplevels stack and initialized. If a toplevel is a IsOverlappedContainer then the Application.Top must be set to the OverlappedTop.

Pull Request checklist:

• I've named my PR in the form of "Fixes #issue. Terse description."
• My code follows the style guidelines of Terminal.Gui - if you use Visual Studio, hit CTRL-K-D to automatically reformat your files before committing.
• My code follows the Terminal.Gui library design guidelines
• I ran dotnet test before commit
• I have made corresponding changes to the API documentation (using /// style comments)
• My changes generate no new warnings
• I have checked my code and corrected any poor grammar or misspellings
• I conducted basic QA to assure all features are working

[BDisp]

@tig I'm tying to re-enabling some unit tests that are commented. One is the Dialog_In_Window_Without_Size_One_Button_Aligns where you have this comment:
// BUGBUG: This seems wrong; is it a bug in Dim.Percent(85)??
and this output:

┌┌───────────────┐─┐
││               │ │
││     [ Ok ]    │ │
│└───────────────┘ │
└──────────────────┘

As you can see the height of the Window is 5. The available height inside is 5-2=3. The proportion is 3/5=0.6x100=60%. This is the ideal percentage for a Dialog, 60% and not 85%. In this case the new dimension is 5x60%=3. If you use the current value the dimension will be 5x85%=4.25, almost 5 which is the same size of the Window. So, I propose to change the Dialog percentage to 60%, at least for the height and the result is this:

┌──────────────────┐
│   ┌──────────┐   │
│   │  [ Ok ]  │   │
│   └──────────┘   │
└──────────────────┘

[BDisp]

@tig we can use the Math.Ceiling on Percent to round up or create an option to that.

internal override int Anchor (int width)
	{
		return (int)Math.Ceiling (width * factor);
	}

See the differences for height of 7:
Expected:

┌──────────────────┐
│   ┌──────────┐   │
│   │          │   │
│   │  [ Ok ]  │   │
│   └──────────┘   │
│                  │
└──────────────────┘
But Was:
┌──────────────────┐
│   ┌──────────┐   │
│   │          │   │
│   │          │   │
│   │  [ Ok ]  │   │
│   └──────────┘   │
└──────────────────┘

[tig]

This is the ideal percentage for a Dialog, 60% and not 85%. In this case the new dimension is 5x60%=3. So, I propose to change the Dialog percentage to 60%, at least for the height and the result is this:

I don't have an issue with this; lots of unit tests will break because we way over-use Dialog for tests that have nothing to do with Dialog, but that's fixable.

@tig we can use the Math.Ceiling on Percent to round up or create an option to that.

This makes sense to me, but again, it'll probably break a lot of unit tests that will need to be fixed.

[tig]

I believe this fix takes Menubar in the wrong direction: It makes it an even more "special" view. IMO, MenuBar (and StatusBar) has too many special cases baked into Application and Toplevel that should all be removed. It should be possible to use Menubar in any View and it should be possible for devs to build other Views that can be used instead of Menubar (or StatusBar).

[tig]

Oooh. Making Height/Width virtual is a HUGE change.

Is this absolutely necessary to fix this Issue?

Subclasses of View that override these need to be coded very carefully. I fear this could be a real bugfarm in the future.

[tig]

This also will make it harder for us to get rid of Toplevel (#2502), and allow any view to act in an overlapping manner.