Coordinating <svg> role mappings between SVG-AAM and HTML-AAM

I was looking up HTML element role mappings and noticed that the HTML
Accessibility API Mapping spec includes mappings for <svg>:
https://w3c.github.io/aria/html-aam/html-aam.html#el-svg

Two things worth noting:

   - That spec does not map <svg> to any existing ARIA role
   - It does, however, map it to the relevant graphics-related roles in
   each API (or group if no appropriate role exists)

In contrast, in the SVG-AAM, we have a generic mapping to ARIA "group" with
a note that it will eventually be replaced with one of the ARIA graphics
roles.  The note also states that "further work is required" to determine
appropriate mappings for each API.
https://rawgit.com/w3c/aria/master/svg-aam/svg-aam.html#role-map-svg

So, things to do:

   - As a start, adopt the platform-specific mappings from the HTML-AAM,
   pending corrections and changes as we develop the Graphics Mapping spec.
   - Coordinate with the HTML-AAM editors to make sure their spec matches
   ours (or ideally, defers to ours) once that change is made.

I really don't want to encourage implementers to use "group" mappings for
SVG elements if better options are available.  It's just too confusing for
screen reader users, and isn't particularly useful for any other AT. The
current graphics mapping proposal is not much better, using generic
"document" roles.
http://rawgit.com/w3c/aria/master/graphics-aam/graphics-aam.html#mapping_role_table

If APIs have roles that convey the graphical nature of content while also
allowing child content to be explored, those should be used for <svg>.  I
don't know enough about the APIs and their roles available to know whether
the mappings from HTML-AAM are the best choices.  But this needs to be
sorted out in highest priority so that implementers have something to go on.

~ABR