Editorial: Phrase private methods as brands, not fields

[littledan]

Many people attempting to implement private methods, both in
transpilers and native JS engines, have run into similar sources
of confusion about semantics and optimizability:

• Many have the misconception that each instance of a class with
  private methods has its own copy of that method, as if it were
  written in a field initializer, when actually, the same function
  identity is intended.
• Private methods are designed to have semantics that they can be
  implemented as a single check that the receiver "has" the private
  method, followed by a call of that method, without taking up
  memory space per-instance. However, many implementers are reaching
  for a direct implementation of them as non-writable private fields,
  which ends up taking a large amount of additional space.

To clear things up, this patch rephrases private methods and accessors'
semantics as being based on a brand check, followed by a function call.
Each object has a list of "private brands" it supports, which are
identified by Klass.prototype, for classes Klass which have private
methods or accessors. Private names are considered to have both a
reference to this brand as well as the actual method linked from them.
My hope is that this will be a reasonable first-pass implementation
strategy; there is a note about how to optimize the brand list further.

With this change, the static class features needs some simple changes,
and the decorators proposal needs some larger changes. See
tc39/proposal-decorators#180 for details.

[gsathya]

What is P?

[littledan]

Oh, that should say brand, thanks, will fix.

[littledan]

OK, I'm going to land this patch so it's more easy to read this version. If anyone has concerns with it, please say so here, and I can roll it back.