Fix incorrect function.name for aliased imports

[RichDom2185]

Uses Object.defineProperty to set the correct function.name value for aliased imports in:

• ec-evaluator
• transpiler

Did not do so for interpreter/interpreter.ts due to the deprecation note in #1476.

How to test

Consider the following program:

import { play as asdf } from 'sound';

asdf("test");

Previously, this will result in the following error:

Error: play is expecting sound, but encountered test

Now, it will result in:

Error: asdf is expecting sound, but encountered test

---

Tested with:

• Source §1/2/3/4
• Source §1/2/3/4 Native
• Source §1/2/3/4 Typed
• Source §1/2 Lazy
• Source §4 Explicit-Control
• Full JS

[RichDom2185]

I just have some doubts on the code quality as follows:

[RichDom2185]

Not sure if this is the right move; what are the implications of this? Perhaps someone could verify/advise.

[martin-henz]

I see that you are updating the name property in the function object. But here, are you trying to add the name "Object" to the names of builtins that are visible from Source programs?

[RichDom2185]

I'm not sure if there's a less hacky way to handle this...

[coveralls]

Pull Request Test Coverage Report for Build 7593472306

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.001%) to 82.936%

---

Totals
Change from base Build 7593229382:	-0.001%
Covered Lines:	10896
Relevant Lines:	12709

---

💛 - Coveralls

[leeyi45]

If multiple files alias the same import the name information is lost

// a.js
import { show as s } from 'rune';
export function a(x) {
  return s(x);
}

// b.js
import { show as b } from 'rune';
import { a } from './a.js';

b(0);
a(0);

would theoretically cause the second call to a to display the function's name as 'b' (or vice versa). However, right now we only use the Function.name syntax when throwing errors, so this isn't an issue at the present moment