Make assumeSafeAppend nothrow.

[monarchdodra]

Try two. This time, I was able to mark and certify it as pure.

First: I spliced __setArrayAllocLength into two different functions:

//From:
bool __setArrayAllocLength(ref BlkInfo info, size_t newlength, bool isshared, size_t oldlength = ~0) pure;

//To:
bool __setArrayAllocLength(ref BlkInfo info, size_t newlength, bool isshared, size_t oldlength) pure;
bool __setArrayAllocLength(ref BlkInfo info, size_t newlength, bool isshared) pure nothrow;

The advantages are twofold:

1. We avoid a runtime check for something we already statically know (should, maybe, slightly, improve performance).
2. More importantly, we can mark one of the two functions as nothrow.

Second: I "aligned" the forward declarations of gc_* in rt/lifetime.d with those in core.memory.d: They now declare more or less exactly the same thing, and have the same qualifiers: mostly pure, and mostly nothrow. I'd like to mention that apparently, none of these functions are actually nothrow, since the GC will lock, but apparently, we can assume the GC never throws anyways?

FInally: With the above two conditions, I was able to vertifiably mark _d_arrayshrinkfit as nothrow, which means assumeSafeAppend can also be marked as such. I also marked it as pure: Even though I was not able to mark _d_arrayshrinkfit as such (because of a static variable for GC initialization), functionally, it's pure (That, also, is what the GC does).

[monarchdodra]

@dawgfoto : What do you think about this? This time, I was able to certify the nothrow-ness of assumeSafeAppend.

Currently, it is not pure nor nothrow, making at no-go in a lot of phobos code that could otherwise make great use of this function. It's a shame we can't use it much right now because of this.

If the implementation is "too involved", I wouldn't be against just marking assumeSafeAppend as nothrow. EG: what I did in #553 .

Thoughts?

[MartinNowak]

I didn't yet got to this. I put it on my TODO list.

[monarchdodra]

Unneeded now.