Make compiler aware of output extension when building programs

[HertzDevil]

The compiler is currently unaware of the use of .exe when building a program on Windows, and incorrectly reports about existing files:

>echo 1 > foo
>mkdir bar
>crystal build foo
Error: compilation will overwrite source file 'foo', either change its extension to '.cr' or specify an output file with '-o'
>crystal build -obar foo 
Error: can't use `bar` as output filename because it's a directory

In the above example, it is always foo.exe or bar.exe that is being built, so the existence of a file called foo or bar should not generate an error.

This PR adds .exe right after the output filename is collected from the command-line arguments. The above builds will succeed, whereas files called foo.exe or bar.exe will now block the builds:

>echo 1 > foo.exe
>mkdir bar.exe
>crystal build foo.exe
Error: compilation will overwrite source file 'foo.exe', either change its extension to '.cr' or specify an output file with '-o'
>crystal build -obar foo.exe
Error: can't use `bar.exe` as output filename because it's a directory
>crystal build -obar.exe foo.exe
Error: can't use `bar.exe` as output filename because it's a directory

30f656c extends this to object files on all platforms.

[straight-shoota]

IMO the code for determining the output filename gets quite confusing. Maybe it could use some refactoring?
For example, the calculation of original_output_filename is completely unnecessary if an explicit output file is given.

[HertzDevil]

This PR now adds .exe to all the object files even when cross-compiling. And it reveals that cross-compilation has the same issue on other platforms, because they too automatically add an extension:

# on x86_64-linux-gnu
$ echo 1 > foo
$ mkdir bar
$ crystal build --cross-compile --target=x86_64-linux-gnu foo
Error: compilation will overwrite source file 'foo', either change its extension to '.cr' or specify an output file with '-o'
$ crystal build --cross-compile --target=x86_64-linux-gnu -obar foo
Error: can't use `bar` as output filename because it's a directory

Neither build should produce an error because foo.o or bar.o does not exist. (On Windows or WebAssembly this would be .obj or .wasm instead.)