Feature: Figure out a smart-pointer class strategy for pdfium

[GoogleCodeExporter]

The codebase is badly in need of a unique_ptr and shared_ptr equivalent.  We 
should determine if we are going to use chromium's classes from base/, or if we 
are going to go with the c++11 library, or if we are going to go with something 
else.

Original issue reported on code.google.com by tsepez@chromium.org on 13 Oct 2014 at 11:54

[GoogleCodeExporter]

Additionally, this implies having  a clear ownership model for memory, using 
the smart pointer classes.  Right now, we kick off a delete at any point in 
time and cascade a bunch of code in an effort to clean up.

Another issue is that ref-counting, where used, is still mostly add-hoc with 
ref increments occurring throughout the code rather than in a smart pointer 
class.

Original comment by tsepez@chromium.org on 28 Oct 2014 at 7:55

[GoogleCodeExporter]

https://chromium.googlesource.com/chromium/mini_chromium/ may also be of help 
here should we want to use this "base".

Original comment by tsepez@chromium.org on 15 Jan 2015 at 7:36

[GoogleCodeExporter]

C++11x std::unique_ptr is a way off, owing to portability concerns on the 
Android platform.  I propose for now taking the scoped_ptr.h that breakpad has 
already made standalone, and adding it to pdfium's third_party/base.  Since we 
eventually want to go to std::unique_ptr, and since scoped_ptr is close, I'm 
going to rename this to nonstd::unique_ptr to make replacement easy.

The other half of the problem, shared pointers, remains murky.

Original comment by tsepez@chromium.org on 17 Apr 2015 at 4:27

[GoogleCodeExporter]

https://codereview.chromium.org/1091283002 for unique_ptr.

Original comment by tsepez@chromium.org on 28 Apr 2015 at 9:38