Fix memory mismanagement bug with EventAttachInfo

[MaxBen93]

Why is this change being made?

We detected a latent issue (#267) impacting the reliability of our application(s) using react-native-xaml which appeared to be the result of memory being used after it had previously been freed/released. Although this ocurred most often when being run under Application Verifier, it stands to reason that this issue could potentially be reproduced on any machine at any time.

What is being changed?

There were two main issues here:

1. The EventAttachInfo struct is being updated to hold a property ref-counted std::shared_ptr<XamlMetadata> instead of a reference to a XamlMetadata object

   In effect, the previous implementation meant that the EventAttachInfo was holding on to a pointer to the EventAttachInfo object, completely irrespective of the fact that it was extending std::enable_shared_from_this, so it wouldn't participate in ref-counting. This would allow the object to be destroyed even if we believed there was still a strong reference to it.

2. The EventAttachInfo struct is now passed by-value into the DispatchTheEvent and code-gen'd attachHandlers_t functions, instead of by-reference.

   Since the code-gen'd attachHandlders_t lambdas would basically just capture the EventAttachInfo inside another, nested lambda (which was provided as the callback handler for the XAML control's event), passing by-reference was a dangerous pattern to use. Although this may all happen on the same thread, we know that the XAML event callbacks could happen at any point, much later in the future. So, we can't assume that the original reference to the EventAttachInfo captured in the lambda is actually still valid memory.

While, in theory, we could use std::weak_ptr within the EventAttachInfo as perhaps a more direct replacement for how the EventAttachInfo& was previously being used, the minimal extra overhead of using a strong reference seems to justify reducing the risk of leaving open other latent issues or introducing new issues.

Microsoft Reviewers: Open in CodeFlow

[jonthysell]

Resolves #267

[jonthysell]

Waiting for #270 to get in, then this PR should be able to pass.