Remove unecessary modules in mod.rs files

[Superhepper]

Extra modules such as:

mod lists;
pub use self::digest_list::DigestList;
pub mod digest_list {
    pub use super::lists::digest::*;
}

Does not serve any real purpose and should be removed.

[ionut-arm]

Do you reckon we should just keep the type exports and not make the modules public, to keep the import tree flat?

[Superhepper]

Yeah, just make everything available under structures like it already is. There is no need to provide alternative module 'paths' to the same thing for us. We do not have like backward compatibility to take into consideration here. I think I was the one introduced this a long time ago because the standard library did this. But for us it makes no sense.

[ionut-arm]

Hmm, just noticed something odd. For some reason there's a separate module for non-volatile-related structures. Any reason for that? They seem very similar to the stuff we have in structures.

Would it make sense for me to move them around to structures?

Another question that doesn't really belong in this thread, but I don't want to open a new issue just for it - we have NvPublic, which is very similar to Public, but which currently has conversions to TPM2B_NV_PUBLIC instead of TPMS_NV_PUBLIC (like we had before for Public). Since the change to bring this in line with how Public works would only be additive (we need to implement a NvPublicBuffer, add some conversions both to this new one and to NvPublic, implement marshalling/unmarshalling), is it ok if I only move the types to structures, but otherwise skip these implementations for a future minor release? NOTE: I'm aware the spec has different sections for the NV structures, but that's part of what makes the spec really confusing. The Public/Private structures are also in a separate section that we nonetheless included in structures. It's all a big mess, I'm just hoping we can keep it more contained.

cc @Superhepper @wiktor-k

[Superhepper]

I think the reason for the nv module is because that is how it is laid out in the specification. How the code should be laid out in our source tree is something I have been pondering about for a long time. The reason I have not been able to come up with a good answer is because we want the modules to intuitive to people who uses the crate and reads the specification. So to some degree we have laid things out as the specification has. But the specification in it self is not consistent!! Sometimes it places things under a specific type topic and sometimes it places the types under subsection of structures even though they are perhaps interface types (rant is over).

So would it make sense to move nv to structures? If we look at the specification then the answer is no, but I wouldn't say anything if it ended up there any way.