During Drop table we read the LCP control files to discover which
LCP parts to delete. During these we use a buffer in DBTUP to
read the file. The buffer is big enough to read the file content.
The buffer is however not big enough to handle the call to
decompress_part_pairs.

Similar code exists in restore.cpp that is used during restart.
This code has extended the buffer size to also accomodate the
call to decompress_part_pairs.

The fix is to move the constant in restore.hpp, LCP_CTL_FILE_DATA_SIZE,
to BackupFormat.hpp and use this constant in Dbtup.hpp as well as already
before in restore.hpp.

The bug caused an overwrite of around 45 words to occur, this caused the
following pool variables to be overwritten:
Extent_info_pool c_extent_pool;
Extent_info_hash c_extent_hash;
Page_request_pool c_page_request_pool;
StoredProc_pool c_storedProcPool;

So in example this caused a crash of the first SCAN_FRAGREQ after the
drop table.

The bug only occurs if the dropped table have more than 2003 parts,
otherwise the decompress_part_pairs will not go outside the buffer.
In order for this to happen we have to execute more than 2000 LCPs
where only 1 part is used (this happens when the number of updates
is very small, but still more than 0 updates).

Needed to update allocateBat in restore since the size of the
buffer is now a new constant.

The constant for the buffer size is the maximum of three things,
the maximum file size, the maximum size used during decompress in
memory and the maximum size of the compressed format.

The bat file uses the buffer size to step to the correct array
when there is more than one of those buffers (which there is in
the restore block).