General naming consistencies -- fix + document + ensure best practices moving forward:

**Is your feature request related to a problem? Please describe.**
Too early in the library to have these -- we need to keep backwards compatibility but want to make it consistent/easy to reason about.

Specifically:
1. `a_` versus `plugin` (done to distinctify async)
- When should/should these ever live together?
- Should we have a separate `aio` package? (or `a` or `async` (which isn't allowed)
2. `b_` versus
- Some have these and some don't (`integrations.b_aiosqlite`, etc...)
- Confusing with `a_` (`a` implies async, `b` implies `burr`, `a_b` implies async Burr I suppose?)
- Done initially to disambiguate import names, although not consistently
3. `plugin` -> package extension name configuration
- No clear mapping here
- Makes it really hard to understand what needs to be installed
- Maybe we have live checks -- should probably consistently be using [this tool](https://github.com/DAGWorks-Inc/burr/blob/main/burr/integrations/hamilton.py#L8)

**Describe the solution you'd like**
1. Come up with best practices
2. Document/ensure them, make any migrations needed
3. Figure out how to keep it consistent in the future (open-ended)

**Describe alternatives you've considered**
Chaos :)

**Additional context**
Add any other context or screenshots about the feature request here.

Start by reviewing the integration naming examples in the issue and burr/integrations/hamilton.py, especially the referenced live-check usage. Survey the existing a_, b_, and plugin package names and their installation mappings. Done means the naming rules, required migrations, and a way to keep future integrations consistent are documented and agreed upon.

Written by the indexing model from the issue text.