Placeholder sheets column names update

[overmyheadandbody]

TL;DR: placeholder column names have changed in the official Franklin documentation, the logic isn't set up to handle the new ones. We need to see if we want to follow the new convention OR allow any column names in our logic OR leave the logic as-is.

---

Until recently, the Franklin placeholder documentation suggested that sheets be created with two column: key and value. This is reflected in the current Milo placeholders spreadsheets and is also built into the code.

Franklin has recently updated their documentation to recommend Key and Text as the column names. A spreadsheet authored in this way will result in errors on our pages.

I was hoping to get some input on a few possible approaches I see or get some other ideas:

1. update our placeholder spreadsheets to reflect this new convention and update the code to read the new column names. This, of course, could be error-prone, as we can't be sure all of the consumers make this update instantly. We can also never be sure that the Franklin recommendation doesn't change once more, thus requiring another update in Milo;
2. update the logic to be key name agnostic. A placeholder entry such as {foo: 'keyName', bar: 'someText'} will be translated to {keyName: 'someText'}. This is the most future-proof solution and doesn't require any update from consumers. However, it does entail a bit of extra processing and it wouldn't allow for eventual additional columns in the placeholder spreadsheets. I already see certain fields which have color and/or url columns;
3. we don't change anything and we ask Milo consumers to follow the original key/value convention. This doesn't require any effort from either Milo or its consumers, but it contradicts the official Franklin documentation, which might lead to issues in the future for consumers who only consult the Franklin documentation.

[auniverseaway]

We deliberately deviated from Franklin as we knew "text" was too limiting... as you mentioned, colors, urls, etc. could all feasibly be used as placeholders.

1. Wouldn't do for reasons above.
2. Wouldn't do. We shouldn't try to architect for behaviors we don't know are real-world. It adds complexity for hypotheticals. "Requires extra processing" is a four letter word in my book.
3. Yes. There's a lot of places we deviate from Franklin docs... and in almost every scenario there's really good reasons. Take the entire placeholder concept, they are polluting the global window object and we... are not.