Remove reserved concept of refreshService from the spec

[OR13]

Now that it has been reserved, we can remove the section from the spec and close #981

Alternatively, we can retain the section and remove refreshService from the "reserved properties" table.

---

Preview | Diff

[brentzundel]

This PR should also include a mention in the Revision History section about the change.

[msporny]

Alternatively, we can retain the section and remove refreshService from the "reserved properties" table.

Preview | Diff

Yeah, we're in a weird place w/ the "legacy but reserved properties". There are a few options here:

1. Mark them as at risk (in the section they're about), and to be removed by the end of CR, if there are not at least two implementations for a single type. Don't add them to the reserved properties table.
2. Do item 1 above, AND add them to the reserved properties table and say that the property will remain in the reserved properties table if there are not at least two implementations for a single type. If we do this, we just end up deleting either the section, or the entry in the reserved properties table. That is, we just remove text instead of having to shift text (which sometimes raises eyebrows during CR (and then you have to explain why you're not trying to pull something over on the W3C, that this was an intentional addition to the spec).
3. Do what's being done in this PR, and delete the section, and add it to the reserved properties table.

If we do item 3, we are (possibly) reducing the chances that it gets implemented because the spec doesn't say what to implement. One could argue: "Wait a second, you're expecting people to implement something that's not spec'd?" -- the counter-argument to that could be: "Well, it's spec'd in v1.1 -- do that." -- that whole exchange is a bit shaky on both sides of the exchange.

If we do item 1, then we have to add text after CR, which always requires quite a bit of explanation as to why you're making a normative change so late in the process.

If we do item 2, we just delete something that we warned people we might delete during CR. This, from a process perspective, feels the easiest to me.

Based on that, -1 to merging this PR for two reasons: 1) I'd prefer we do item 2 above (from a process perspective), and 2) I already know that there are at least two independent implementations of this feature -- TruAge, and a digital wallet vendor that can probably speak more openly about this in a couple of months.

I have attempted to demonstrate what 2 would look like in this PR: #1115

[decentralgabe]

+1 @msporny I prefer an "at risk" approach. I believe this should be closed in favor of #1115

[OR13]

Closing the PR, I think the working group is making big mistakes by keeping stuff like this around, instead of adding it back when it is ready, git preserves history, but it only takes one reading of this section to be mislead into believing these features have interoperability.