Fix error introduced in r167687 and add copy constructor to PersistentHeapVector.

Source/core/html/shadow/TextControlInnerElements.h

Index: Source/core/html/shadow/TextControlInnerElements.h
diff --git a/Source/core/html/shadow/TextControlInnerElements.h b/Source/core/html/shadow/TextControlInnerElements.h
index d18fd8c3ab569ca9a07496ebf9bd9ba3fc5c132c..1d96b62b8493ee512fe901e24a1bf3aca3a6185e 100644
--- a/Source/core/html/shadow/TextControlInnerElements.h
+++ b/Source/core/html/shadow/TextControlInnerElements.h
@@ -134,7 +134,7 @@ private:
     bool m_capturing;
     SpeechInputState m_state;
     int m_listenerId;
-    SpeechInputResultArray m_results;
+    PersistentSpeechInputResultArray m_results;

[Mads Ager (chromium), 2014/02/26 09:38:41]

WillBePersistentSpeechInputResultArray to make it clear that there is a
transition type involved here?

[haraken, 2014/02/26 09:43:15]

I slightly disagree. We've not used "WillBe" for typedefs. The advantage of not
using "WillBe" in typedefs is we don't need to edit a lot of places when
switching to real types :)

[Mads Ager (chromium), 2014/02/26 09:49:06]

In this particular case, having Persistent in the name might be indication
enough. However, it is not a persistent when compiling without enable_oilpan so
the name is slightly misleading. If we could consistently use
SpeechInputResultArray I agree that we don't need the WillBe prefix. When we
move InputFieldSpeechButtonElement to the heap we can completely remove this new
typedef. It is just temporary naming so I don't feel that strongly about it. :-)

Overall, these typedefs are a little dangerous as this change shows. When using
a transition type in a typedef we really need to find all usages and check that
they are traced with enable_oilpan.

 };
 
 DEFINE_TYPE_CASTS(InputFieldSpeechButtonElement, Element, element, element->isInputFieldSpeechButtonElement(), element.isInputFieldSpeechButtonElement());