web: add additional analytics to toggle ApiButton interactions

[lizzthabet]

To prep for the disable resources launch:

• Add toggleValue property to toggle button analytics to indicate what the value for toggle is when the user clicks on it
• Add toggle button analytics tags to the confirm/cancel buttons
• Reorganize and add more types and constants for ApiButton

The toggleValue property will help us know if a user is clicking disable or enable on a resource. I could see this value being potentially confusing because it doesn't represent the value that will result from the user interaction. But because a user could confirm or cancel their toggle, I think it's fine to record the value "pre" toggle.

Here's what a disable resource button click looks like:

{
  "action": "click",
  "buttonType": "DisableToggle",
  "component": "Resource",
  "specHash": "9ac7c2a31917ba7ca7ca",
  "toggleValue": "on"
}

and a confirmation button click:

{
  "action": "click",
  "confirm": "true",
  "buttonType": "DisableToggle",
  "component": "Resource",
  "specHash": "9ac7c2a31917ba7ca7ca",
  "toggleValue": "on"
}

A cancel button click will have confirm: "false", but otherwise look the same as above.

Will link a related pr for the schema documentation shortly!

Closes CH13015.

[shortcut-integration]

This pull request has been linked to Shortcut Story #13015: (non-launch blocker) Analytics test.

[nicks]

would it be better to leave off the tag completely if it's not defined, like the original code did? otherwise, i think you might end up with a bunch of {tag: "undefined"} in analytics?

[lizzthabet]

that's a great question! i believe that serializing to json drops properties that are undefined (JSON.parse(JSON.stringify(tags)) does), but i'm not 100% sure of that. it's probably faster for me to make the code change than test my assumption out.

if anyone else knows, lmk for my curiosity. 🕵🏻‍♂️