Restructure the project for new versioning approach

[ItsDrike]

This PR resolves #45, and restructures the entire project to no longer support multiple minecraft protocol versions, moving to a single (latest) version model.

Note that this is a completely breaking change, and there will NOT be a deprecation period. This is because of how this change impacts the rest of the project development. As this project is still in pre-release stage, deprecation here would greatly slow down any further development here, forcing contributors to maintain both the temporary deprecation layer, and the new single-version one.

For more details on how this change will affect the project going forward, and why it is necessary, I'd suggest checking out #45, containing a detailed explanation.

I have updated the README examples which now use this new version, so I'd suggest checking that out before moving forward with trying out this version, or reviewing the code, as it demonstrates how this new approach will work. Note that when testing this version out, it will almost certainly break any existing code-bases using mcproto, checking the README changes and looking at the changelog fragment message should make it clear on how to update.

---

Some decisions I made here, which I find potentially worth considering during a review. I'm open to doing these differently:

• The generate_packet_map function is dynamic - imports the appropriate libraries on function run, depending on the requested packets. The alternative here would be to simply hard-code packet maps dictionaries as constants. This could be done either in the new packet_map.py file, but also in the individual game state folders for the packets, such as mcproto.packets.login import CLIENTBOUND_MAP.
• The generate_packet_map uses caching, to avoid needlessly re-importing the modules and walking over all of the packets again. The clear downside of this is the fact that it uses more memory, though that's almost irrelevant as packet maps are relatively small.
• Because of how caching works, since we're returning a mutable dictionary from generate_packet_map, the cache would hold the same reference as the returned dict, potentially causing issues if the user modifies that returned dict. For this reason, I decided to also add another decorator, responsible for copying the result afterwards, making sure that the cache holds a different instance of the dictionary, and what users see is simply a copy of this instance, which they can modify or do whatever they wish with, without risking breaking future calls to this function. For this reason, the function will now only return a mapping proxy, which is immutable, and holds a strong reference to the dict internally (as suggested by @Martysh12).

[Martysh12]

That looks good to me, but that last point bugs me a little.

• I like the idea of importing packets dynamically, as maintaining a big dictionary of packets does seem like a pain.
• I don't mind the memory overhead caching gives the library, because importing is a slow procedure.
• Is it possible to return some kind of "immutable dictionary", so that you don't have to copy the dictionary? Maybe MappingProxyType from the types module? (available since Python 3.3)

[ItsDrike]

Is it possible to return some kind of "immutable dictionary", so that you don't have to copy the dictionary? Maybe MappingProxyType from the types module? (available since Python 3.3)

This is a nice idea, however you need the real dictionary to be kept somewhere, and since a function call creates a new stackframe, with all of the variables in it, as the function ends, that stackframe gets deleted, and that means taking all of the local variables it held alongside. A mapping proxy needs a reference to an actual dict object, so we can't have that dict going out of scope, while the mapping proxy is returned.

You could probably do something hacky, like crating a global variable, holding a list of dictionaries, which are the return values, so that the caching then returns that mapping proxy back, with the actual dict being in that global variable list. But this is probably way too convoluted and I'm not sure I love that.

I do also find this caching with copying pretty annoying though, I just wasn't able to think of anything better. Btw, do you think the name utils/decorators.py works well here? Or can you think of a better name? I didn't want an overly specific name just for this copying logic, to avoid too many files in utils dir, but decorators might be a bit too broad. Not sure where else to put it / what to call that file.

[ItsDrike]

Hmm, actually after some testing, it seems like this would work, as MappingProxyType does count as an object holding a direct reference to the original dict, so it's more like returning a class holding a dict inside of it. I assumed mapping proxy worked more like a weakref. In this case I would agree that just returning a mapping proxy would probably work pretty well.

[Martysh12]

This is a nice idea, however you need the real dictionary to be kept somewhere, and since a function call creates a new stackframe, with all of the variables in it, as the function ends, that stackframe gets deleted, and that means taking all of the local variables it held alongside. A mapping proxy needs a reference to an actual dict object, so we can't have that dict going out of scope, while the mapping proxy is returned.
You could probably do something hacky, like crating a global variable, holding a list of dictionaries, which are the return values, so that the caching then returns that mapping proxy back, with the actual dict being in that global variable list. But this is probably way too convoluted and I'm not sure I love that.

Riiight. Oh well, copying is not that bad after all.

Btw, do you think the name utils/decorators.py works well here? Or can you think of a better name? I didn't want an overly specific name just for this copying logic, to avoid too many files in utils dir, but decorators might be a bit too broad. Not sure where else to put it / what to call that file.

I can't think of a better name than utils/decorators.py, so I guess it's final.

I'll approve the changes, then.