easy: Test env propagation behavior and refactor based on that

[luciusmagn]

In our async Command wrapper, there is this monstrosity:

testauskameli/testauskameli/src/cmd.rs

Lines 69 to 89 in 3ad1f5c

	.env("KAMELI_FILELIMIT", $self.file_limit.to_string())
	.env("KAMELI_MEMLIMIT", $self.mem_limit.to_string())
	.env("KAMELI_PROCESSLIMIT", $self.proc_limit.to_string())
	.env("KAMELI_TIMELIMIT", $self.time_limit.to_string())
	.arg("env")
	.arg(&format!(
	"KAMELI_FILELIMIT={}",
	std::env::var("KAMELI_FILELIMIT").unwrap_or($self.file_limit.to_string())
	))
	.arg(&format!(
	"KAMELI_MEMLIMIT={}",
	std::env::var("KAMELI_MEMLIMIT").unwrap_or($self.mem_limit.to_string())
	))
	.arg(&format!(
	"KAMELI_TIMELIMIT={}",
	std::env::var("KAMELI_TIMELIMIT").unwrap_or($self.time_limit.to_string())
	))
	.arg(&format!(
	"KAMELI_PROCESSLIMIT={}",
	std::env::var("KAMELI_PROCESSLIMIT").unwrap_or($self.proc_limit.to_string())
	))

An astute observer might recognize, that this is not nice cock.

Tasks:

• Try removing either one or the other and see how these propagate - use the cli program, so you can test Testauskameli from the comfort of your Unix-compliant computer. you can use the following snippet for seeing what's up:

cat <your-test-input> | env RUST_LOG="testauskameli=debug" cargo run -p cli

• Try one of the snippets, maybe haskell or c, or something. Look into their runner script (located under bin/) and insert echo $VARs for the variable(s) you are testing
• You should find out, if the env invocation from line 73 is needed, or if just the method calls above are enough

Recipe:

• if the method calls are enough, yeet the lines 73-95
• if they aren't, yeet lines 69-72

In case they aren't, report here, because we will need smarter refactoring, especially with regards to this:

testauskameli/testauskameli/src/cmd.rs

Lines 90 to 95 in 3ad1f5c

	// this needs a better solution
	// TODO: unhardcore
	.arg(&format!(
	"GHC_ARGS={}",
	std::env::var("GHC_ARGS").unwrap_or_default()
	))