This fixes an issue with the Datetime component where in certain
circumstances a ref on an element rendered by the datetime component
would end up erroneously set to null, necessitating a yucky
document.querySelector based workaround.

The issue arises because of how Stencil's virtual DOM implementation
handles reconciling the children of old and new nodes, and in particular
how it deals with situations in which the order of children changes but
some of the nodes are conserved.

The way this was affecting the datetime component was that in certain
circumstances a method which returns a <div> with a ref would change
position in the children of another node. In particular, this can happen
if the presentation prop changes, causing the return value of the
renderDatetime function to change in turn. The salient changes to
the return value of that function which would change look like
going from:

[
  this.renderCalendar(mode),
  this.renderTime()
]

to

[
  this.renderTime(),
  this.renderCalendar(mode)
]

renderCalendar in turn calls renderCalendarBody which returns the
<div> with the offending ref on it.

Anyhow, in reconciling these changed children when re-rendering the
component things can go wrong. Stencil's algorithm in this case does a
"best effort" at identifying nodes which should be kept between
re-renders, but it does not do an exhaustive check unless nodes have a
key attr. So, more or less, what was happening was that in cases where
the <div> with the ref on it was going to be included in the next
rendered output from the component Stencil would nonetheless remove the
'old' node and create a new identical one for the next render. Then
there is also a race condition where the new node would be created
before the old one is removed, causing the ref to be briefly set to
the new value (when the new VNode is created) and then reset to null
(when the old one was destroyed).

The fix is to set the key attribute on the <div> which is the
parent of the <div> with the ref. This allows Stencil to do an
exhaustive check when reconciling old and new children in order to
not needlessly throw away the old VDom node, and gets rid of the
behavior where the ref would end up set to null erroneously.
It's possible (but I think unlikely) that this change will result
in slightly less GC pressure, but I did no testing of that.

closes stenciljs/core#3253
FW-901

Pull request checklist

Please check if your PR fulfills the following requirements:

• Tests for the changes have been added (for bug fixes / features)
• Docs have been reviewed and added / updated if needed (for bug fixes / features)
  • Some docs updates need to be made in the ionic-docs repo, in a separate PR. See the contributing guide for details.
• Build (npm run build) was run locally and any changes were pushed
• Lint (npm run lint) has passed locally and any fixes were made for failures

Pull request type

Please check the type of change your PR introduces:

• Bugfix
• Feature
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no api changes)
• Build related changes
• Documentation content changes
• Other (please describe):

What is the current behavior?

There is a bug in Stencil which this fixes (stenciljs/core#3253).

Basically, there was an issue where switching the presentation prop on the Datetime component would erroneously set a ref stored on the component to null. This fixes that by setting a key attr on the relevant div so that Stencil's VDom child reconciliation / update algorithm can do a better job of finding nodes that are the same between renders.

Issue #3523

What is the new behavior?

Does this introduce a breaking change?

• Yes
• No

Other information