Clarifies that class must be used if available

[rbergen]

Clarifies the contributing guidlelines on the points that:

• a class is the (only) allowed construct if a language provides one
• if it isn't but alternatives are, the one closest to the class concept must be used
• a class instance needs to be created from scratch for every sieve run

[bbartels]

I really don't want to come across as pedantic, but this class rule seems rather arbitrary. There is no language independent definition of a class. I feel like the primary objective here was to require: some language construct that allows for the encapsulation of state. Which is a significantly more precise definition, than class.

I don't particularly care about this rule being one way or another, just seems like a well defined ruleset would avoid confusion going forward :)

[rbergen]

Of course I accept your opinion as your opinion, but the new phrasing of the rule actually more accurately expresses the intent of the original rule. Generally speaking, classes are the most "heavily burdened" by OO concepts (like support for inheritance and default maximum isolation) in those languages where there is a difference between it and similar constructs. In languages where there is no performance penalty to using classes, arguing against them is moot in the context of this repo's primary goal, The 3 original languages use the class construct, so that is the premise for the project.
Maybe we could be accused of being too lenient by allowing similar constructs in languages that don't actually have classes, but excluding all of them would have excluded (too) many languages that make this repo interesting to many people, not in the last place Dave himself.

Concerning avoiding confusion: we're really doing our best and that on a daily basis, I guess we'll have to conclude that with this many people engaging with the project, it is impossible for a very finite group of people to fully anticipate the collective creativity of a much larger, and constantly growing, group of people. As this PR's description states, its aim is to reduce confusion on one specific point where it has clearly arisen.

[sglienke]

Another rule that makes no sense imho. If you want to enforce this, then also force that the instance has to be heap-allocated because most languages cannot stack allocate like C++ for example can. To avoid pointless heap allocations structs and alike can be used in other languages.
Some of those rules are way too coupled towards implementation details of the original languages and impose irrational requirements on other implementations. The rules should thus be defined in a more abstract and language agnostic way.

[rbergen]

As I explained in #382, the rules are indeed strongly inspired by the original solutions, and that by choice.