[changed] Replace appElement with getAppElement

[claydiffrient]

This makes getAppElement a required prop as well as makes
it a function that will be called expecting a DOMElement.

closes #287

This also takes some inspiration from #359 for handling arrays
of objects.

Fixes #[issue number].

Changes proposed:

• Remove appElement in all it's forms
• Add getAppElement as a function prop

Upgrade Path (for changed or removed APIs):

• If you had specified an appElement via Modal.setAppElement,
  then you need to convert that to a getAppElement prop on the
  modal, this should be a function that returns either a single
  element or an array of elements.
• If you had nothing specified you will need to add the getAppElement
  element to prevent breakages.

Acceptance Checklist:

• All commits have been squashed to one.
• The commit message follows the guidelines in CONTRIBUTING.md.
• Documentation (README.md) and examples have been updated as needed.
• If this is a code change, a spec testing the functionality has been added.
• If the commit message has [changed] or [removed], there is an upgrade path above.

[diasbruno]

show() has the same effect if it sets ae.setAttribute('aria-hidden', 'false');, so hide() and show() could betoggle(appElement : DOM, value : bool).

[claydiffrient]

Good call :)

[dminuoso]

This solution elegantly tackles #133 too.

[dminuoso]

One thing that I've been thinking about is the change to always require a getAppElement prop.

Does defaulting to () => document.body make sense perhaps?

[claydiffrient]

@dminuoso No unfortunately it doesn't make sense. If you do that then all the body ends up hidden from screen readers which definitely makes it non-accessible. We've got that in v1 currently and there are lots of sites out there that get completely hidden from screen readers because of it.

[priyajeet]

@claydiffrient are there any plans to back port this to version 1 for issue #133. Or when will V2 have a release soon (beta or otherwise)? Thanks!