Odd dimensions not handled in half sampling

[kvmanohar22]

This could probably save someone hours of debugging down the line.

This occurred while testing on KITTI sequences.

Here is report using valgrind.

==3017== Invalid read of size 16
==3017==    at 0x5A73A5E: vk::halfSample(cv::Mat const&, cv::Mat&) (in /home/kv/slam/svo/rpg_vikit/vikit_common/lib/libvikit_common.so)
==3017==    by 0x4E6ECF9: svo::frame_utils::createImgPyramid(cv::Mat const&, int, std::vector<cv::Mat, std::allocator<cv::Mat> >&) (in /home/kv/slam/svo/svvo/lib/libsvo.so)
==3017==    by 0x4E6F4C4: svo::Frame::Frame(vk::AbstractCamera*, cv::Mat const&, double) (in /home/kv/slam/svo/svvo/lib/libsvo.so)
==3017==    by 0x4E5E74D: svo::FrameHandlerMono::addImage(cv::Mat const&, double) (in /home/kv/slam/svo/svvo/lib/libsvo.so)
==3017==    by 0x407CE8: svo::BenchmarkNode::runFromFolder() (in /home/kv/slam/svo/svvo/bin/kitti)
==3017==    by 0x4060E4: main (in /home/kv/slam/svo/svvo/bin/kitti)
==3017==  Address 0x1ab06eae is 1 bytes after a block of size 7,309 alloc'd
==3017==    at 0x4C2DE96: malloc (vg_replace_malloc.c:309)
==3017==    by 0x538CE33: cv::fastMalloc(unsigned long) (alloc.cpp:64)
==3017==    by 0x54C727A: cv::StdMatAllocator::allocate(int, int const*, int, void*, unsigned long*, int, cv::UMatUsageFlags) const (matrix.cpp:190)
==3017==    by 0x54C8221: cv::Mat::create(int, int const*, int) (matrix.cpp:417)
==3017==    by 0x4E6EC1A: svo::frame_utils::createImgPyramid(cv::Mat const&, int, std::vector<cv::Mat, std::allocator<cv::Mat> >&) (in /home/kv/slam/svo/svvo/lib/libsvo.so)
==3017==    by 0x4E6F4C4: svo::Frame::Frame(vk::AbstractCamera*, cv::Mat const&, double) (in /home/kv/slam/svo/svvo/lib/libsvo.so)
==3017==    by 0x4E5E74D: svo::FrameHandlerMono::addImage(cv::Mat const&, double) (in /home/kv/slam/svo/svvo/lib/libsvo.so)
==3017==    by 0x407CE8: svo::BenchmarkNode::runFromFolder() (in /home/kv/slam/svo/svvo/bin/kitti)
==3017==    by 0x4060E4: main (in /home/kv/slam/svo/svvo/bin/kitti)
==3017== 

[kvmanohar22]

Although this is not a fix, this at least warns someone of the problem ahead. This issue is also raised in #15 and #18.

@cfo Please have a look into this.