Add annotation for statically ordered options

[DavidArthurCole]

Came up in one of the SH PRs I'm working on - because config classes can be extended, and truly make use of inheritance, order is unknown before runtime currently, due to the collection process.

This PR adds an annotation to specify a ConfigOptionOrder, which specifies how options are gathered.

Also, unrelated to this, this project specifically likes to create a .kotlin folder in my intellij, so I added it to gitignore 🥺

[lineargraph]

Pretty sure the current order for inheritance is very much deterministic with fields of the base class being above fields in the inheriting class. Is that not the observed behaviour? Either way, i am unsure about using more magic integers. I suppose in this case it is more about moving things above and below children, so there is not much to be done in terms of keeping children in sync, but i am still not sure i am a huge fan. That is not a deal breaker, just something i want some time to think about.

[DavidArthurCole]

Pretty sure the current order for inheritance is very much deterministic with fields of the base class being above fields in the inheriting class. Is that not the observed behaviour?

I can provide a more concrete example, but, it's more about a mix of inheritance & overriding that causes problems. For example:

open class ConfigClassA {
   @ConfigOption(...)
   val x = ...
   
   @ConfigOption(...)
   open val y = ...
}

When using inheritance to create a sub-class:

class ConfigClassB : ConfigClassA() {
   @ConfigOption(...)
   override val y = ...
}

When ConfigClassB is used, the override for y will appear before the inherited x does.