Normalize the representation of the :number and :string functions

[eemeli]

From #39 (comment):

@dminor:

I think this would be more readable if you added a CreateMessageFormatNumberFunction abstract operation, instead of having the _numberSteps_ followed by CreateBuiltinFunction.

@eemeli:

Heh, I actually had them that way in an earlier draft. Happy to do that, esp. if @ryzokuken agrees.

The current function steps definition language is modelled after that used for e.g. Promise Resolve Functions and Number Format Functions. The language on this line follows what seemed like the most common way of calling CreateBuiltinFunction(), though Intl.NumberFormat.prototype.format does something a bit different:

Let F be a new built-in function object as defined in Number Format Functions (15.5.2).

My main reason for this approach was that this way the :number and :string definitions can be left without the boilerplate code that's now here. But my opinions on this are not at all strong.

@ryzokuken:

This has me equally stumped. On the one hand I agree with @dminor that an AO would be much more readable and less arcane than this.

On the other, I understand the connection to the other similar parts of the spec. I still lean towards AOs over dynamically creating ES builtin functions because my understanding of the MF2 builtin registry functions is that they'd not be actually dynamic and therefore we'll be fine by using an AO here.