Kill the fopen()s in pdfium code base.

[GoogleCodeExporter]

These won't work in a sandboxed environment, and indicate either:

1. Places where the code is unreachable, or
2. Places where functionality is genuinely broken.

For case #2, add a sdk API for the embedder to provide the data, taking safety 
into consideration (!!!).

Original issue reported on code.google.com by tsepez@chromium.org on 5 Feb 2015 at 7:49

[GoogleCodeExporter]

Original comment by tsepez@chromium.org on 5 Feb 2015 at 7:49

[GoogleCodeExporter]

One of the questions we have to resolve is how we view the role of pdfium in 
products different from chromium; should we allow others to build products that 
might support, say,

FX_BOOL Document::exportAsFDF(OBJ_METHOD_PARAMS)
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/pdfium/fp
dfsdk/src/javascript/Document.cpp&rcl=1423113308&l=323

by routing that JS method to an embedder API call, or should we just kill that 
path entirely?

Original comment by tsepez@chromium.org on 5 Feb 2015 at 8:43

[GoogleCodeExporter]

for the current fopen's, when are they used? I think you mentioned fonts 
before? IMO if so, we should remove them and have one way which is to use the 
existing font embedder interface. We can move that code to it in pdfium_test as 
an example of what's needed.

for exportAsPDF, what is that used for?

Original comment by jam@chromium.org on 5 Feb 2015 at 8:47

[GoogleCodeExporter]

Note that it's exportasFDF (with an F) in case you're searching around for it 
online.

Original comment by tsepez@chromium.org on 5 Feb 2015 at 9:06