Add new_manual constructor so that crate can be used with damaged fil…

[cr1901]

…esystems.

I'd like to use this crate to carve up a damaged drive image. Unfortunately, this crate expects the BPB to be present, and in my image, the BPB is one part that is probably gone for good.

By analyzing the good parts of the image (I hope to automate it using heuristics eventually), I've figured out the required NTFS parameters to make ntfs-shell happy.

This is my earnest attempt at implementing functionality described on Fedi. It is the minimal additional functionality I need, and doesn't include ntfs-shell changes in the link. As an example, that should probably be kept minimal. I can- have continue to :P- modify it.

My question is: should this be unsafe? Am I breaking any invariants by allowing a user to inject possibly-fake parameters into a new Ntfs struct? Or will the Ntfs struct "parse and fail if the data looks incorrect" without invoking UB.

My own experience with hardcoding NTFS parameters and running ntfs_shell on my image seems to be that this crate's functions/methods will (correctly) immediately bail if things don't look right. But happy to add unsafe to my function if it's too difficult to verify.