Debug symbols on macOS

The build script builds Python with debug symbols, but on macOS the debug symbols are not embeded in the executable, they stay in the object files if compilation and linking are done separately, so the shipped executable is missing debugging info. A separate call to `dsymutil` would be needed to package the debug symbols in a dSYM bundle that could be distributed with the package.

Also, since Python is built with link time optimization, a linker flag would have to be added the the link command.

Full explanation (from https://github.com/conda-forge/gdb-feedstock/pull/23/#issuecomment-643008755):

> * on macOS, the full debug info is never stored in the executable. It is either left in the object files, and the executable just keeps a record of the paths to the object files, or it is put into a "dSYM bundle".
> * when compiling and linking in a single step with the clang/clang++ drivers and the `-g` flag, i.e.
> ```
> clang -o app -g main.cpp Matrix.cpp Vector.cpp cholesky.cpp ...
> ```
>
>
> the driver automatically calls `dsymutil` at the end of the process to create this dSYM bundle. (this can be seen by adding `-v` to tell the driver to output all commands it issues.)
> * when compiling and linking in separate steps, which is usually the case with Make- or Automake- based build systems, the driver does _not_ call `dsymutil`, so the debug info is left in the object files.
> * When compiling and linking in a single step with `-flto`, the driver calls the linker with the `-object_path_lto` flag and a path in` $TMPDIR`, eg. `-object_path_lto /var/folders/lr/r6n2057j0dzd4gdb614fp0740000gp/T/cc-ac0bf8.o`.
> * when compiling and linking in separate steps, the driver does _not_ add this option to the linker call.
> * `man ld` reveals that if `object_path_lto` is not used, the linker deletes the temporary file used for link time optimization after the linking step is finished.
>
> The last point means that the final executable keeps a reference to this deleted temporary file (I guess `/tmp/lto.o` is hardcoded in ld64's source code, I did not check that). So when the executable is loaded in GDB, the debugger tries to load the debugging symbols from the now deleted temporary file.
>
> Adding `-Wl,object_path_lto,lto.o` to the linking command (in a Makefile for example) leaves the object file used for link time optimization (here `lto.o`) in the build directory, which allows to debug the executable. It also allows calling `dsymutil` manually to create the dSYM bundle.
>
> References:
>
> * `man ld`
> * https://stackoverflow.com/a/12827463/ (written by an Apple developper)
> * http://wiki.dwarfstd.org/index.php?title=Apple%27s_%22Lazy%22_DWARF_Scheme (written by the same Apple developer)
>
> Of course having debug symbols distributed with a conda-forge package would have to be discussed on each package's feedstock. It would mean telling the build system of each package to add the flag `-Wl,object_path_lto,lto.o`, adding a call to `dsymutil` in `build.sh`, and copying the dSYM bundle to the recipe prefix.

**Note**: this issue is kind of orthogonal to other already opened issues (#73, #86, https://github.com/conda-forge/conda-forge.github.io/issues/1017), since building Python with debugging symbols is different from a ["pydebug" build of Python](https://devguide.python.org/setup/#compile-and-build)