Ensure that `convert_project` works with compilation databases that use the `command` field

[mattmccutchen-cci]

convert_project currently has some logic that only works if the compilation database (compile_commands.json file) uses the arguments field rather than the command field:

checkedc-clang/clang/tools/3c/utils/port_tools/generate_ccommands.py

Lines 152 to 163 in 2a0df40

	# BEAR uses relative paths for 'file' rather than absolute paths. It
	# also has a field called 'arguments' instead of 'command' in the cmake
	# style. Use that to detect BEAR and add the directory.
	if 'arguments' in i and not 'command' in i:
	# BEAR. Need to add directory.
	file_to_add = i['directory'] + SLASH + file_to_add
	compiler_path = i['arguments'][0]
	# get the compiler arguments
	(compiler_x_args,
	output_filename) = getCheckedCArgs(i["arguments"][1:])
	# get the directory used during compilation.
	target_directory = i['directory']

It seems that, knowing this, we've mostly standardized (notably, in the benchmark workflow) on using compilation databases that use arguments (as generated by Bear) rather than command (as generated by cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON), and we haven't made much of an effort to address the command case in recent changes to convert_project. (To be clear, that "we" is mostly me.) I did a simple test with cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON, and the 3C run seemed to work, but the macro expander didn't work at all.

Ideally, all of our tools should support all important features of the Clang compilation database specification. command is the main feature we are missing; output might also be worth considering where it is relevant (e.g., for the macro expander). We can start with convert_project. Some of our utils-5c tools may also need work, notably compdb build; we can file a separate issue in the utils-5c repository if we want.