Allow advanced markers to be used in block form

[acorncom]

I've been working on a client project where we're beginning to adopt advanced markers. The work that @colenso did on #192 has been much appreciated. But as I work with them further, I'm starting to hit a few use cases where having the ability to work with advanced markers in block form would ease some of the UI interactions we're working to build out.

TL;DR

We're seeing two items that block form would unlock:

1. Use block form would make it easier to provide more content for advanced marker elements. Passing strings into @content works well enough for SVG markup, but gets messy when dealing with more complex templates and reacting to state changes / rendering additional components
2. Adding event handlers to the marker element beyond what is available in the relatively limited set of event options gets complicated if UI needs demand

My suggestion is we allow using markers as block elements if desired. This doesn't wish anything new on existing consumers but gives us both the ability to register additional modifiers on the core content element and greater flexibility with the HTML rendered within the marker

<GMap
  @lat="51.507568"
  @lng="-0.127762"
  @zoom={{9}} as |map|>

  <@map.advancedMarker
    @position={{this.position}}
    @onClick={{@onClick}}
    {{this.contextMenu @onContextMenu}}
  >
    <div class="fancy-decorations-here {{this.selected}}">
      <svg>
      </svg>
    </div>
  </@map.advancedMarker>
</GMap>

Background

We're currently setting up SVG marker elements using a getter which allows us to react in basic ways to state changes. That has worked reasonably well for us over the last few years.

But that combination started breaking once we needed to register additional custom events on the AdvancedMarkerElement beyond what our common onEventName approach handles or what the default element emits. In our case, we specifically want to allow context menu interaction with a given marker element. The fact that the default don't have this makes complete sense (context-menu pop-ups aren't common when dealing with markers) but in our particular use case, they're both quite helpful and intuitive.

But switching to passing through our own custom element as a @content value ended up breaking default event handler registration (could dig in on this further if needed, but was seeing it break both onClick and onDragend event handlers). Accessing the built / rendered AdvanedMarkerElement from JS is in theory possible but we currently lack an element in the DOM to register handlers against:

  <@map.advancedMarker
    @position={{this.position}}
    @onClick={{@onClick}}
    {{this.contextMenu @onContextMenu}}
    {{! this fails }}
  >

More comments on the PR itself

[acorncom]

We only set this div up optionally to reduce overhead for consumers that don't want this behavior

[acorncom]

By passing our domElement in here, any event fired by Google continue to work but we also have the ability to register our own

Completely happy to clean up the way we're handling options here, mainly wanted to send this over so we could see it / discuss it

[acorncom]

@colenso / @sandydoo would love to get your input on this. We're currently building a feature out using these changes and it's working well