Do not check backing field presence in AnnotationSplitter

This code can be invoked early, during body resolution and before the
fact that a property has backing field (which is only known for certain
after body resolution, because an implicit 'field' identifier may be
used). Since split annotations are cached until the end of the program,
they may end up on incorrect elements in the bytecode (or disappear
completely) as in KT-29507 or KT-28182.

Because the FIELD target has the lowest priority among implicit
annotation targets (see TARGET_PRIORITIES), it's safe to always assume
that FIELD is a valid target when splitting annotations. This only
changes the way annotations are split in case of incorrect code, as
changes in test data show.

 #KT-28182 Fixed
 #KT-29507 Fixed

compiler/testData/diagnostics/tests/annotations/withUseSiteTarget/FieldAnnotations.txt

@@ -17,8 +17,8 @@ public final class CustomDelegate {
 
 @Ann public final class SomeClass {
     public constructor SomeClass()
-    protected final val delegatedProperty: kotlin.String
-    public final val propertyWithCustomGetter: kotlin.Int
+    @field:Ann protected final val delegatedProperty: kotlin.String
+    @field:Ann public final val propertyWithCustomGetter: kotlin.Int
     @field:Ann protected final val simpleProperty: kotlin.String = "text"
     @field:Ann protected final val simplePropertyWithAnnotationList: kotlin.String = "text"
     public final fun anotherFun(/*0*/ s: kotlin.String): kotlin.Unit