Support options for automated conversion of casings

[niknetniko]

Currently, all code is converted to the appropriate casing, e.g. functions in JavaScript are converted to camel case, while they are snake case in Python.

However, this is sometimes not what you want. For example, not all programming languages are fully consistent. Some Python packages do have camel case or e.g. toJSON in JavaScript.

We should have a way of indicating that some functions do not need to be converted.

[pdawyndt]

In this exercise we initially wanted to have the first method be a static method, but calling the static method as Class.method(...) was rewritted by TESTed as class.method(...). So this could be a use case for the support that is asked in this issue (*).

(*) In addition, we might need specific support for static methods, because the syntax for calling static methods differs from the syntax for calling non-static methods in some programming languages.

[pdawyndt]

In BibTeX casing is preserved for characters that are enclosed in curly braces:

title = "Pascal, {C}, {Java}: were they all conceived in {ETH}?"

Maybe we can do something similar, perhaps using double curly braces as in the Jinja2 templates for task descriptions. Later we might even use these curly braces for other use cases (e.g. i18n), but for now they might preserve what's inside if given as a string enclosed in single or double quotes?

[niknetniko]

Another idea we had from a IRL talk is using the convention for magic Python methods (e.g. __double_leading_and_trailing_underscore__) for identifiers that need to remain the same.

For example, writing some_variable.__toJSON__() would result in someVariable.toJSON() in JavaScript. The name of the variable is handled as normal, the name of the function is left alone.

This does re-use an existing Python convention, but the chances of us using magic Python methods in the DSL are very slim.

[niknetniko]

After implementing the solution with underscores as described above, it became clear that this does not work for constructors and global variables (since constructors are identified when they start with a capital and global variables must be all caps).

We currently do not see a clean solution using the underscore mechanism, so we would need workarounds.

Additionally, it is less clear how useful this feature is now that we support language-specific code. The question is are there cases where we want to override the automated casing conversion but still have something language-agnostic? For example, the toJSON example is not such a case, since it is JavaScript-specific, in which case the language-specific construct is enough.

I have thus closed the PR with the underscore implementation, and propose we revisit this issue once we have more exercises or use-cases.