Added streaming support to Face

[MnemonicWME]

The Face class now provides a constructor which accepts Stream as a parameter. The stream must support reading and seeking.
Callback functions for reading/seeking and closing the external stream are provided by the Face class (StreamIOFunc, StreamCloseFunc). I changed the delegates to accept IntPtr as an opaque pointer to the stream FT_Stream structure, instead of NativeReference.
The stream is open during the entire duration of Face existence. The user can choose whether it should be disposed together with the Face or not (using the takeStreamOwnership argument when creating Face).

The goal here is 1) to allow the user to access fonts via some custom virtual file system 2) to avoid the necessity of loading entire font into memory

[MnemonicWME]

Note for WIN64: freetype6.dll will need to be recompiled, because some additional fields must be patched in freetype source to allow proper interop. I updated the win64.patch file in this PR.

[HinTak]

Sounds good. Could solve
#89

[HinTak]

When you do "new StreamAccessor(stream, takeStreamOwnership)" in the constructor, is there a potential problem of it going out of scope and getting garbage-collected on the C# side?

Anyway, I seem to have a practical problem with your change - throwing 1500 fonts on fedora at it (actually all 3200+ fonts, but the CFF fonts are filtered by my C# side code and does not pass through to freetype), about 150 of them comes back with a corrupted memory problem "read or write protected memory" or " Object reference not set to an instance of an object", after running for a while. Re-running those 150 fonts files give me another 50 successes; etc. And I can gradually cut down the number of failures down to about 20 after about 30 further repeats. The last 18 seems to be especially hard. This is obviously file layout and access-pattern dependent. @MnemonicWME - so do you think your code might have a problem with garbage-collection ? The fact that re-running gives successes certainly sounds like it. Before this change - when I pass the file name itself onto freetype and let freetype re-open by file names, I have rarely had this. But adopting this change is meant to give me the ability of opening files with non-ascii names.

[HinTak]

I changed to keep the two new () in the constructor, and got it down to 15. So the verdict is that about 1 in 10 (147 in about 1500) fails in first run; if you keep re-running the failed ones, some of them eventually will succeed. But I have 15 would would not after more than 40 re-tries. So that makes 1 in 100.

[HinTak]

Any thought about intermitent failure with this change? @MnemonicWME