In groovy the presence of a getVersionCode/getVersionName allows the syntactic sugar flutter.versionCode/versionName. You can read about this here
https://www.groovy-lang.org/objectorientation.html#properties

By convention, Groovy will recognize properties even if there is no backing field provided there are getters or setters that follow the Java Beans specification. For example:

class PseudoProperties {
    // a pseudo property "name"
    void setName(String name) {}
    String getName() {}

    // a pseudo read-only property "age"
    int getAge() { 42 }

    // a pseudo write-only property "groovy"
    void setGroovy(boolean groovy) {  }
}
def p = new PseudoProperties()
p.name = 'Foo'                      (1)
assert p.age == 42                  (2)
p.groovy = true                     (3)

(1) writing p.name is allowed because there is a pseudo-property name
(2) reading p.age is allowed because there is a pseudo-readonly property age
(3) writing p.groovy is allowed because there is a pseudo-write-only property groovy

But then having a versionCode property, a getter for that property, and also a getVersionCode property causes an error because Kotlin implicitly names the getter getVersionCode. So I'm renaming the generated getter name here, because it doesn't actually matter what it is (all that matters is that we have an equivalent for the syntactic sugar that Groovy was generating, i.e. referencing it as flutter.versionCode).