This is take 2 after 924a808c (golang: Fix `@func(cls) def name` not to
override `name` in calling context). There we fixed it not to override
name if name was already set, but for the case of unset name it was
still set. The following example was thus not working correctly as
builtin `next` was shadowed:

    class BitSync

    @func(BitSync)
    def next(): ...         # this was shadowing access to builtin next

    def peek(seq):
        return next(...)    # here next was taken not from builtin, but
                            # from result of above shadowing

To solve the problem in the patch from 2019 I initially contemplated
patching bytecode because python unconditionally does STORE_NAME after a
function is defined with decorator:

    In [2]: c = """
       ...: @fff
       ...: def ccc():
       ...:     return 1
       ...: """

    In [3]: cc = compile(c, "file", "exec")

    In [4]: dis(cc)
      2           0 LOAD_NAME                0 (fff)
                  3 LOAD_CONST               0 (<code object ccc at 0x7fafe58d0130, file "file", line 2>)
                  6 MAKE_FUNCTION            0
                  9 CALL_FUNCTION            1
                 12 STORE_NAME               1 (ccc)	<-- NOTE means: ccc = what fff() call returns
                 15 LOAD_CONST               1 (None)
                 18 RETURN_VALUE

However after hitting this problem for real again and taking a fresh
look I found a way to arrange for the good end result without bytecode
magic: if name is initially unset @func can install its own custom
object, which, when overwritten by normal python codeflow of invoking
STORE_NAME after decorator, unsets the attribute.

That works quite ok and the patch with the fix is small.

/cc @jerome
/proposed-for-review-on !28