Fixing keyboard support in Drawers

[sophialee0416]

Platforms Impacted

• iOS
• macOS

Description of changes

In #1936 , there was a bug fix for drawers not being able to support expand with keyboard if the drawer was presented in a custom-set origin. This is because we automatically calculate the frame origin on contentFrame.maxY - contentSize.height, which is not necessarily always the correct origin especially if a keyboard is in use. The keyboard height code is also simplified so that it is more accurate in the presentation calculations.

Binary change

(how is our binary size impacted -- see https://github.com/microsoft/fluentui-apple/wiki/Size-Comparison)

Verification

Manual tests below, no change should be observed, since the bug was found in the PopupMenuController that had a search bar. Hypothetically, if a drawer with a unique origin point that goes up prompts a keyboard to appear, the bug should appear. This should also only affect presentations that go .up.

Example (pre bug-fix):

Without keyboard engagement	With keyboard engagement

Visual Verification

Before	After
	!

Pull request checklist

This PR has considered:

• Light and Dark appearances
• iOS supported versions (all major versions greater than or equal current target deployment version)
• VoiceOver and Keyboard Accessibility
• Internationalization and Right to Left layouts
• Different resolutions (1x, 2x, 3x)
• Size classes and window sizes (iPhone vs iPad, notched devices, multitasking, different window sizes, etc)
• iPad Pointer interaction
• SwiftUI consumption (validation or new demo scenarios needed)
• Objective-C exposure (provide it only if needed)