std.experimental.allocator API and nearly useless StatsCollector

[Luis]

Well, this last week I was playing using malloc/free to do some 
@nogc code, and using the std.experimental.allocator API. Also, I 
was trying to see a way to profile my code and search for memory 
leaks, etc...

What I initially did, was implementing my own allocator API plus 
my own mallocator, seeing how ECS buble engine does this.
Later, I take a look how std.experimental.allocator API works and 
I ended writing my own wrapper above make, makeArray, dispose, 
expandArray & shrinkArray that implements this profiler/stats, 
and using std.experimental.mallocator .
Finally, I catch that I can only use my wrapper on my code, and 
that I couldn't use on other third party libraries that allow to 
use allocators (like EMSI Containers), because (obviously) uses 
the std.experimental.allocator API.
Then, I discover 
std.experimental.allocator.building_blocks.stats_collector that 
looks that does what my littler profiler does, and more. But I 
see tiny detail that I don't see totally ok.

The stats that are reported by reportPerCallStatistics, shows the 
file & line number of the allocator!

Like this :

```
/usr/include/dmd/phobos/std/experimental/allocator/package.d(1585): [numAllocate:1, numAllocateOK:1, bytesAllocated:40]
```

This could be useful for someone writing his own allocator, but 
it's pretty useless for anyone trying to track where a memory 
leak originated in his own code!

On my wrapper, What I did was to have a `string file = __FILE__, 
int line = __LINE__` parameters append to the make, makeArray, 
dispose, etc... functions and uses the file and & line to record 
where something was allocated/deallocated/reallocated.

So, why std.experimental.allocator API not does something similar 
to this ? The allocator implementations, would need to pass & 
ignore these two additional parameters. Except StatsCollector 
that can use it to show where the 
allocation/deallocation/reallocation it's happening