feat(python)!: Split python pack into seperate smaller packs

[Uzaaft]

This allows an end-user to more easily "stack" the python packs based on the tooling they use in their d2d work. A big breaking change but with the direction python tooling is going, I think its the move.

[github-actions]

Review Checklist

Does this PR follow the [Contribution Guidelines](development guidelines)? Following is a partial checklist:

Proper conventional commit scoping:

• If you are adding a new plugin, the scope would be the name of the category it is being added into. ex. feat(utility): added noice.nvim plugin

• If you are modifying a pre-existing plugin or pack, the scope would be the name of the plugin folder. ex. fix(noice-nvim): fix LSP handler error

• Pull request title has the appropriate conventional commit type and scope where the scope is the name of the pre-existing directory in the project as described above

• README is properly formatted and uses fenced in links with <url> unless they are inside a [title](url)

• Entry returns a single plugin spec with the new plugin as the only top level spec (not applicable for recipes or packs).

• Proper usage of opts table rather than setting things up with the config function.

• Proper usage of specs table for all specs that are not dependencies of a given plugin (not applicable for recipes or packs).

[Uzaaft]

Would appreciate some feedback @azdanov and @mehalter

[Uzaaft]

Doing this would allow us to add pyrefly, ty etc with less headache.

[azdanov]

I wonder if it's still needed for backwards compatibility?

[azdanov]

Just a thought, but are nested packs are supported? To have pack.python.basedpyright, pack.python.isort, etc.

[mehalter]

My guess is probably. We could probably have them in a python folder and then the submodules would work. Also we could have an init.lua file in that folder that would still allow users to do: astrocommunity.pack.python and get a basic base setup that could just import the submodules.

[Uzaaft]

Actually pack.python.{package} would slap. I like that idea. I can refactor this to follow that pattern instead.

Also we could have an init.lua file in that folder that would still allow users to do: astrocommunity.pack.python and get a basic base setup that could just import the submodules.

Issue with this is that they might and probably will conflict.

[mehalter]

It would allow people to get a "base" config or they can build their own with the pieces