Heap allocations when copying non-view storages

[cristicbz]

Because of the way views are implemented, an extra ref-counter is needed to store the number of views pointing to the same matrix object, in addition to the counter counting the number of objects pointing to the same memory used for copy-on-write.

Unfortunately this means whenever a non-view storage is copied, it creates a new RefCounted pointing to a copy of the underlying container. Since RefCounted heap-allocates memory on construction, it means something as innocuous as a matrix-matrix copy, while not copying the underlying data, still performs a heap allocation.

With the current design, the only way to alleviate this would be to provide a custom RefCounted type which uses a free list custom allocator.

Note:This would not help with the extra pointer indirection, but I've no idea how to remove that; however, ideally, performance-critical operations will be done using matrix ops, thus avoiding many quick-succession data accesses. When this cannot be avoided, one always has the option of using the .data & .cdata properties directly, with the proper precaution.

[dsimcha]

I just realized this stuff may be unnecessary because people can use ExternalMatrixView / ExternalVectorView as a dangerous-but-efficient way of interfacing with SciD, using explicit allocation for everything but temporaries that are created during evaluation of an expression, if the performance hit from SciD's nice but expensive abstractions is unacceptable. I just noticed that an equivalent to ExternalMatrixView for triangular, symmetric, etc. matrices exists and to get at it you just do e.g. DiagonalMatrix!(double).Temporary. This needs to be documented and perhaps renamed to External. That would be an elegant naming system: To get the external equivalent to T, just do T.External.