Use F-macro for flash-strings, conserves SRAM

[rambo]

---------------------------- DO NOT DELETE OR EDIT anything above this line ----------------------------

Hey there! Thanks for using the SPIFlash library for Arduino.

Please note that starting 01.03.2018 any Pull request raised here MUST be submitted according to this template or it will be flagged with 'Not enough information'. No action will be taken till all the prerequisite information is provided. If no information is provided for over a month, the pull request will be closed.

Pull request details

• Please check if the PR fulfills these requirements

• The commit message/s explain/s all the changes clearly
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

• What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

• Bug fix
• Added feature
• Documentation update
• Other - Please explain here:

Use the F() macro to load strings from "flash" (program memory) instead of having them
all initialized in SRAM

• What is the current behavior? (You can also link to an open issue here)

Serial.print("String"); all over the place

On worst case scenario all of those strings are statically allocated and initialized in SRAM on boot
I have not checked how the compiler handles allocation of strings in methods on different platforms but would expect it's all static.

• What is the new behavior (if this is a feature change)?

Serial.print(F("String"));

This macro stores the string in program memory from where it's read one byte at a time when used,
conserving SRAM (there is of course clock-cycle overhead involved but it's small and one would not be printing strings to the serial port if one needed to squeeze the last bit of performance out of the mcu anyway).

• Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)

I have not tested this on every "Arduino compatible" platform but I would expect the macro to be
no-op where the platform does not support (or need) the functionality. I've tested this on Teensy3.2 and it does work (haven't actually compared the compiler details on statically allocated RAM so not sure if it actually does anything on the ARM Cortex-M4)

• Other information: