cmake: generate and install pkgconfig file

This installs the x265.pc into /usr/local/lib/pkgconfig/ with these contents:

prefix=/usr/local
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: x265
Description: H.265/HEVC video encoder
Version: 0.4.1
Libs: -L${libdir} -lx265
Libs.private:  -lstdc++ -lm -lc -lpthread -lrt
Cflags: -I${includedir}

The pkg-config file is only generated and installed if CMake finds pkg-config

Q1: it seems unwise to hard-code "/lib" in a few places, what if lib64 is
used or something else?
Q2: Should x265.pc have a version number like x265-0.4.1.pc?

--HG--
branch : stable
CSV log: Enable frame-by-frame CSV logging

--HG--
branch : stable
api: large reorg of logging and statistics

* move all CSV logging into the encoder so API users can take advantage of it
* remove hacky global PSNR return value from x265_encoder_close
* add time and bitrate values to x265_stats_t
* remove some dead HM code
* use x265_log in the CLI

--HG--
branch : stable
api: white-space cleanups in x265.h

--HG--
branch : stable
api: drop _t suffix from public data types, for POSIX compatibility

x265_t was changed to x265_encoder, since x265 is too short and would collide
with our namespace.

--HG--
branch : stable
extra : amend_source : 0b5ed45990de2efbd9a31d6c5da138b2a7988f94
Displaying the number of weighted P frames used in console log

--HG--
branch : stable
encoder: fix bitrate statistic (accBits is a bit count, not byte count)

--HG--
branch : stable
output: use 64bit file offsets to prevent overflow with 4k video

--HG--
branch : stable
input: If Any error in reading frame from file, deactivate the thread and exit encoder gracefully

--HG--
branch : stable
lookahead: fix reference initialization for intra prediction

buffer size of pAbove/pLeft is height+1+width = 2*cusize+1

--HG--
branch : stable
TComPicYuv: remove unused include

--HG--
branch : stable
TComPicYuv: fix padding of picture buffers

Ensure row starts are at a multiple of 32, this causes strides to be multiple
of 64.  Before this patch, strides we capable of being multiples of 8, causing
alignment exceptions for some videos.

--HG--
branch : stable
weightp: use source reference frames for weight analysis

This fixes weightp when used in combination with frame parallelism, where the
reference's reconstructed picture is most likely not yet avaialable.

Some measurements using the sintel 480p clip
no-weightp -F1: 408.47s (3.07 fps), 144.63 kb/s, Global PSNR: 48.956
no-weightp -F3: 361.14s (3.47 fps), 144.01 kb/s, Global PSNR: 48.746

Prior to this change (recon refs used for weightp analysis):
weightp -F1: 402.84s (3.11 fps), 131.09 kb/s, Global PSNR: 49.908
x265 [info]: 278 of 687 (40.47%) P frames weighted
weightp -F3: 355.88s (3.52 fps), 132.09 kb/s, Global PSNR: 49.768
x265 [info]: 242 of 687 (35.23%) P frames weighted

After this change (source refs used for weightp analysis):
weightp -F1: 404.83s (3.10 fps), 131.82 kb/s, Global PSNR: 49.414
x265 [info]: 325 of 687 (47.31%) P frames weighted
weightp -F3: 348.32s (3.60 fps), 131.01 kb/s, Global PSNR: 49.957
x265 [info]: 325 of 687 (47.31%) P frames weighted

Because of the lower bitrate, enabling weightp actually makes this clip encode
faster.  No idea why -F1 has so much less PSNR than -F3; needs investigation.

--HG--
branch : stable