[WString] Reduce build size by implementing flash string calls in .cpp

[TD-er]

A function called with a flash string, which only has an implementation with const String& as argument will be compiled as if it is called with a String constructor wrapped around it.

For example this implementation in the .h file:

bool startsWith(const __FlashStringHelper *prefix) const {
            return this->startsWith(String(prefix));
}

This is completely useless as the compiler will generate exactly the same code with or without this function implementation in the .h file.
However if we move the implementation to the .cpp file, this conversion to String is only added once in the compiled binary.
In my own project I already managed to shrink the largest (ESP32) build by more than 70k in size (!!) by just adding extra function calls with the conversion in the .cpp file.
This PR is just a simple optimisation which already shrinks a very small build of my project by almost 3k in build size. (custom_beta_ESP8266_4M1M PIO env of ESPEasy)

Flash: [========  ]  82.5% (used 862137 bytes from 1044464 bytes)
Flash: [========  ]  82.3% (used 859545 bytes from 1044464 bytes)

Larger builds may benefit even more.

[mcspr]

I think it's also worth to mention strncmp_P, which could be used for const char* & FlashStringHelper, instead of String(...) conversion? Leaving basic strncmp for the String.
(and since we already assume that const char* could be PSTR(...) with other const char methods)

[TD-er]

Yep for those that can accept const char* that would be an option for sure as you don't need to copy the data from flash if not needed.
Would not make the build smaller, but the memory consumption would benefit from it.

Especially the webserver part would benefit from a similar approach as I have seen that sending flash strings directly to the webserver would make it incredible fast, but also highly unstable when running low on free memory. So if it doesn't need to copy flash strings to memory first but serve it directly from flash string (without the need to copy internally).
And I guess there are other areas too where it could be very useful to have such optimizations.

[earlephilhower]

Very nice idea! I think your app might be the single largest user of Strings in the world, so most others won't see quite so dramatic a change, but this still seems like a great addition once the 3.0.x bugfixes are in and released.

[TD-er]

[...] I think your app might be the single largest user of Strings in the world [...]

:)
Could be. The largest ESP32 build just passed the 2M build size.