Remove compat javascript behaviour for string concatenation

[MaxGraey]

This pull request removes JS behaviour for null-sh strings like this:

Before (master)

const path = "/dev/" + null; // actually needs changetype<string>(null)
// > "/dev/null"

After (this PR)

const path = "/dev/" + null;
// > "/dev/"

Also removed null checks for concat, startsWith and endsWith.

• I've read the contributing guidelines

[MaxGraey]

So anther approach suggested by @vgrichina is throw exception for null strings during concat operation. But in this case we probably should propagate this strict behaviour for rest strings methods as well. Thoughts?

UPD. Pretty many smart people voted for throw an error which more stricter

[saulecabrera]

I had to think about this a bit before voicing my opinion. I believe that in the end, all of this boils down to consistency as @battlelinegames mentioned yesterday in the meeting; if one of the principles of the language is to be as close as possible to JS, then as a user I'd expect these quirks to be there, especially when other typed languages that target JS like TS keep this behavior too. Continuing with the consistency line of thought, if we decide on removing it, then we should clearly state under what principle we decided on removing it, and probably the sanest thing to do moving forward is to apply that "improvement" principle to all the other JS quirks (where possible obviously). In reality, though, improving JS could represent breaking changes, but such discussion falls again under the bucket of what level of compatibility we want to have with it.

TLDR; there's no doubt that this behavior can be improved, and people will vote or share their opinions based on how that improvement can be made, but I think that the bigger discussion here is about the principles of the language rather than how to approach the actual feature.

[MaxGraey]

@dcodeIO could you review this?

[dcodeIO]

Is it correct to assume, from the diff, that if there is any breaking change in the PR it is in the __gt signature, which is more like a bugfix since __lt doesn't have nullable types?

[MaxGraey]

Yes I guess it's breaking change due to some of signatures was changed

[dcodeIO]

Considering to label this one a "fix", as it merely fixes that one signature that is different from all the others. Wdyt?

[MaxGraey]

Up to you. I don't think it should significantly affect to existing user's code. So it could be marked as fix or feat (improvments/simplification)