Prohibit function call macro to const translation

[Remmirad]

closes #803

Tackles the issue, that C macros consisting of a function call are translated to rust const expressions which do not compile and are not semantically equivalent.

As described in the code comment there might be a more thorough way to do this but that would, as far as i can tell, at the least require some redesigning of how C2rust handles/represents sideeffects and only would increase performance a bit in a special case, as described in the issue. So for now this here might suffice.

The fix I wrote here stops C2Rust from producing code that does not compile in this case and achieves the behavior that one would expect: All occurrences of the macro in code are replaced by the function call.

I also added corresponding test for this situation.

[fw-immunant]

Thanks for the PR.

Unfortunately, I don't think this approach is what we want here. Forbidding call expressions on the Rust side is too restrictive (due to const fns), and unfortunately so is forbidding call expressions on the C side (due to builtins which we may translate to Rust builtins or const fns).

As this feature is experimental, I think it's best to simply leave it uncomplicated for now. --translate-const-macros is only useful for the simplest cases, and we don't have a clear path toward making it useful everywhere.

[fw-immunant]

This can be written more simply:

Suggested change

	let expr = match expr.result_map(|v| {
	if matches!(*v, Expr::Call(_)) {
	Err(())
	} else {
	Ok(v)
	}
	}) {
	Ok(v) => v,
	Err(_) => return Err(format_err!("Can not expand macro to function call")),
	};
	let expr = expr.result_map(|v| {
	if matches!(*v, Expr::Call(_)) {
	Err(format_err!("Macro definition contains function call"))
	} else {
	Ok(v)
	}
	})?;

[fw-immunant]

The purpose of to_unsafe_pure_expr is not actually to enforce the kind of purity that Rust consts require. It checks a notion of purity based on "does the expression computing this value have prerequisite statements that we need to ensure are evaluated prior to the expression itself".

We sadly don't have a good notion of "is this Rust expression const-safe", and it's difficult to build one because c2rust is oriented toward reasoning about C code, not Rust code. See this comment.