Fixed a crash related to computed enum member keys

[Andarist]

Enum members are in the scope of the enum declaration as this is allowed:

declare const enum E {
  foo = "foo",
  foobar = foo + "bar",
}

That allows the identifier in the computed key to attempt resolving in the same way. However, that leads to a cycle with enums:
getDeclaredTypeOfEnum(E) -> hasBindableName -> isLateBindableName -> checkComputedPropertyName -> checkExpression -> checkIdentifier -> getNarrowedTypeOfSymbol -> getTypeOfSymbol -> getTypeOfEnumMember(E.foo) -> getTypeOfEnumMember -> getDeclaredTypeOfEnumMember -> getDeclaredTypeOfEnum(E)

Given enums can't really have computed keys (as shown in the added tests given the reported "TS1164: Computed property names are not allowed in enums." diagnostic), the simplest fix is to just check if the member !hasDynamicName(member) instead of hasBindableName(member) (the latter calls || isLateBindableName(member))

fixes #63173

[jakebailey]

Can you explain the fix?

[Andarist]

@jakebailey sure, edited the PR summary

[typescript-bot]

With 6.0 out as the final release vehicle for this codebase, we're closing all PRs that don't fit the merge criteria for post-6.0 patches. If you think this was a mistake and this PR fits the post-6.0 patch criteria, please post to the 6.0 iteration issue with details (specifically, which PR and which patch criteria it satisfies).

Next steps for PRs:

• For crash bugfixes or language service improvements, PRs are currently accepted at the typescript-go repo
• Changes to type system behavior should wait until after 7.0, at which point mainline TypeScript development will resume in this repository with the Go codebase
• Library file updates (lib.d.ts etc) continue to live in this repo or the DOM Generator repo as appropriate