Fix for computing blob size without loading entire blob content in memory - Fix #873

Fix for computing blob size without loading entire blob content in memory - Fix #873.

Summary of the fix - 
Added a new public method GetObjectSize in ObjectDatabase class which takes ObjectId as input and returns object size. Underneath this calls git_odb_read_header native method to read the header of the object. The header contains Object Type and size. The size is returned as an int value here.

Detailed summary - 

1- Added a new public method GetObjectSize in ObjectDatabase class which returns the Object size for a given Object Id.

2- Added a new class ObjectHeader, which stores the size and type of an object. This is in agreement with the return values of underlying libgit function git_odb_read_header, which is called underneath to fetch this information from ODB.

3- Added a wrapper around git_odb_read_header method to return an ObjectHeader C# object containing size and type info of the queried git object.

4- Added a unit test GetObjectSizeReturnsCorrectSizeForBlob which creates an empty repo, adds a new blob to it, and then verifies that the value returned by repo.ObjectDatabase.GetObjectSize(blob.Id) is same as blob.Size.

Verified this on my local setup with a repository which has about 50K files on the tip. Seems to work fine.

Thanks @ethomson for suggesting the solution and @jamill  for helping me out on the implementation and testing.
I feel like we're casting away a lot of bits here.  I realize we'll never have a blob this large, but we'll definitely never have a *negative* sized blob, so I'd like to see this be a `ulong`, I think.