imporvements to uninitializedFill && initializeAll

Because they didn't really handle all of the cases correctly.

Added unittests.
"Ranges..." => "Needles..." in [starts|ends]With.
To avoid any confusion: The stuff in ranges may or may not actually be ranges. generic "Needles" is what best describes it.
Clean up endsWith unittests
Original author wrote "wrap" because filter is not bidirectional. However, the function filterBidirectional fits the need, so migrating to that.
Bit of unicode unittest in [starts|ends]With
Just sprinkling some tests. These covered a wee little bit of missing usecases.
Optimizations in startsWith
* Consolidate implementation by checking length in a single spot.
* Checks narrow string or the same types' lengths.
* Index iterates on all RA ranges (and not just Arrays).

Ends with was left untouched, because it forwards to startsWith anyways.
Optimization in startsWith(Range, Needles...)
Basically, makes it stop searching as soon as an element as matched.

This is an important optimization, that avoids a lot of startsWith's other "non-optimzations"...
std.array.join refactor.

tl;dr: std.array.join was quite complicated: 6 implementation functions, and a few hundred lines of code. Now it is just 2 functions, ~120 lines of code smaller, and within 10% performance of original (faster in some cases).

The original had 6 implementations: 3 joins with a separator, 3 without. For each, those 3 consisted of:
* A general slow version (uses `std.algorithm.joiner` with `appender`).
* A version for a range of arrays where you know the length (pre-allocates the destination array then uses array ops).
* A version for a range of arrays where you don't know the length (uses `appender`).

There's no need for the second version because you can just use appender and `.reserve` the size upfront. Appender already uses array ops when available in its `put` function.

There's also no need for the first function because using `joiner` is slower than just looping through the sub-ranges, appending them. The third function doesn't even use the fact that its operating on a range of arrays, so it can easily be merged with the first and second.

The end result is just one function for join with a separator, and one for a join without. They both use `appender`, and have a static branch that will `.reserve` the required size when the information is available.
Fix for mismatched string types + added unittests.
Convert sep to array for performance/generality.
Fix for non-array separators for non-string RoR.
More improvements and optimisations to array.join
Changed foreach to for to avoid copies + cleanup
Merge pull request #1043 from dnewbie/master

Set CA certificate
Merge pull request #1036 from Poita/array-join-refactor

std.array.join refactor.
Make joiner (with separator) work with forward ranges and transient ranges.

This is for the variant of joiner that takes a separator.

Restructure algorithm to not call .popFront while we're still using
.front.

Make sure we .save subranges when we're exporting .save, since RoR.save
does not guarantee the state of subranges are also .save'd.
Add unittests for new joiner with separator.

Comment out assert which will segfault when passed a range of class
objects, because the .init value of a class object is null, and
.init.empty is a null dereference.
Explain necessity of setItem being a mixin.
Merge pull request #1020 from quickfur/joiner_sep_fixes

Fix transient and forward range bugs in joiner with separator
Implement nextPermutation for bidirectional ranges.
Implement nextEvenPermutation.