[FIR] KT-55840: Ensure everything actually works

This inconsistency is present due to not using the `// WITH_STDLIB`
in the above tests. When K1 creates the enum, it tries to generate
`entries()`, and for that it tries to load `kotlin.enums.EnumEntries`,
but this is actually an unresolved reference. K1 silently swallows it,
and proceeds.

The reason K2 doesn't fail is that in order to generate `entries()` it
simply creates the necessary `ConeClassLikeType` with the desired
`classId` instead of loading the whole `ClassDescriptor`.

The reason we can still observe `$ENTRIES` and `$entries` in K1
is because they are generated during the JVM codegen, and it
only checks if the `EnumEntries` language feature is supported. It
doesn't check if the `entries` property has really existed in IR
(by this time it's expected to have already been lowered to the
`get-entries` function - that's why "has ... existed").

The reason why the codegen doesn't fail when working with
`kotlin.enums.EnumEntries` is because it creates its
own `IrClassSymbol`.

^KT-55840 Fixed

Merge-request: KT-MR-8727
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>

compiler/testData/codegen/asmLike/typeAnnotations/enumClassConstructor.asm.ir.txt

@@ -25,6 +25,10 @@ public class foo/Kotlin : java/lang/Enum {
 
     public void <init>(java.lang.String $enum$name, int $enum$ordinal, java.lang.String s, kotlin.jvm.internal.DefaultConstructorMarker $constructor_marker)
 
+    ()Lkotlin/enums/EnumEntries<Lfoo/Kotlin;>;
+    public static kotlin.enums.EnumEntries getEntries()
+      @Lorg/jetbrains/annotations/NotNull;([]) // invisible
+
     public static foo.Kotlin valueOf(java.lang.String value)
 
     public static foo.Kotlin[] values()

compiler/testData/codegen/asmLike/typeAnnotations/enumClassConstructor.kt

@@ -1,3 +1,4 @@
+// WITH_STDLIB
 // IR_DIFFERENCE
 // EMIT_JVM_TYPE_ANNOTATIONS
 // RENDER_ANNOTATIONS