Fix String initialization in GCC 4.8.5

[mikee47]

This PR fixes the instablity problems related to the String class since #1951. The problem is present only in Linux with GCC 4.8.5, which silently ignores the union intializer and member variables are left un-initialised at construction time.

This is the initializer which causes the problem:

	union {
		struct {
			size_t u32[STRING_OBJECT_SIZE / 4] = {0};
		};
		PtrBuf ptr;
		SsoBuf sso;
	};

Simplifying it has no effect:

	union {
		PtrBuf ptr = { nullptr, 0, 0 };
		SsoBuf sso;
	};

So it seems something to be avoided generally.

The solution, therefore, is to add a default constructor which does the initialisation and ensure it's used by all the other constructors.

This has been tested using HostTests build and flashed in a Linux VM.

Note that this PR also addresses another GCC 4.8.5 annoyance in its limited ability to handle constexpr functions. This means the HostTests can be built in Linux.

[aemseemann]

This is exactly the issue mentioned in #1817. (BTW: I can't express enough my appreciation for the gdbstub integration, which was incredible helpful in tracking this down.)

However, may I suggest to take care of another minor issue within this PR:
In #1951, the following overload was introduced:

int indexOf(const char* s2_buf, size_t fromIndex = 0, size_t s2_len = 0)  const;

This breaks common patterns like haystack.indexOf("needle"), because of the default argument s2_len = 0, i.e. the search string is truncated to an empty string which is always found at position 0. Before SSO, a const char * argument was implicitly converted to a String and correctly handled by the indexOf(const String&, ...)` overload.

My suggestion would be something like this:

int indexOf(const char* s2_buf, size_t fromIndex, size_t s2_len)  const;
int indexOf(const char* s2_buf, size_t fromIndex = 0)  const
{
    return indexOf(s2_buf, fromIndex, strlen(s2_buf));
}

[slaff]

This PR fixes the instability problems related to the String class since #1951

Tested and confirmed to do the work. @mikee47 when you have time check @aemseemann comment.

[mikee47]

@aemseemann Yes, I agree yours is a much better way to handle this - thanks for pointing it out. I'll make the change.

[slaff]

@mikee47 Thanks a lot for your help!

[mikee47]

I broke it so I should fix it!

[etmmahi]

Thanks for the fix, my 'develop' code is working again