Make `-fPIC` optional.

[cemeceme]

I am using please to handle the building of STM32 projects and most of the required flags and tools are possible to implement by defining them within a .plzconfig file.
However, it looks like please always adds the -fPIC flag to the compiler flags.
It is possible to override this by defining -fno-pic in the compiler_flags section of the c/cc build rules, however this is no longer a project-wide solution as defining all the flags in .plzconfig.

The code is being compiled by arm-none-eabi-g++ instead of the default tool and the inclusion of the -fPIC flag forces the definition of a global offset table in the STM provided linker scripts, as well as potentially adding some extra overhead that isn't necessary.

I realize embedded is not necessarily the goal of the cc-rules, but I have grown to really like please and would like to use it to build all my projects, including embedded code. It's certainly versatile enough to do so!

[Tatskaari]

I think this makes a lot of sense. I wonder if @peterebden has any context as to why we add this flag here rather than just having it part of default flags config options? is it just that it's so commonly needed for general computers, and we didn't really consider embedded applications?

I wonder if we could address this in v2 of these rules while addressing some of the issues here: #9

[peterebden]

I honestly can't remember why -fPIC is injected that way. I wonder if it's something about ordering given the comment, but seems we should be able to achieve that anyway by adding to the default flags.

I guess it could technically be breaking if we move it from here to the defaults (because then you wouldn't get it if you overrode it in particular ways). On the bright side, we still haven't reached 1.0 yet so we're allowed to do that \o/

I wasn't specifically aiming at embedded with these, but there also shouldn't be anything that specific about them; I like the idea that they can be applied to that use case as well!