Leverage Array.Copy and List<T>.CopyTo in FastLinqExtensions

[TheXenocide]

Somewhat nitpicky from code reviewing Shaman.FastLinq, but Array.Copy uses native memory copying (sometimes down the the processor instruction level, depending on platform/architecture) which can be much faster than manual iteration. List<T>.CopyTo uses Array.Copy internally. Given enough elements or a hot enough path, the savings might be substantial. Very basic benchmarking on my windows machine using classic .NET indicates that Array.Copy executes between 1/3rd and 1/5th the time of manual iteration. .NET Core appears to maintain this option, though I'm not aware of what the various platform implementations actually do, I suspect their worst case is manual iteration.

As an additional note, the constructor List<T>(IEnumerable<T>) internally checks the type of the supplied enumerable. If it is ICollection<T> it uses ICollection<T>.CopyTo, otherwise it iterates. This may be faster than the current FastLinq implementation, or at least simplifies the logic of public static List<TSource> ToList<TSource>(this List<TSource> array) which simply becomes => new List(array);

Some of these optimizations may be useful for IList<T> or ICollection<T> as well.

Sidenote: This is a pretty cool project; thanks for sharing it. I'm actually not using this code currently, I arrived here while researching Roslyn-based pre-compilation transformations as I was thinking it might be a powerful way to implement AOP. Do you do anything to map symbols to the original source code lines?