feat: decouple plugins from framework.

[brent-hoover]

Right now your plugins need to be in a very specific place in the structure of the project for them to work. Most people using a framework will want to keep their custom plugins separate from the framework code. A couple of issues now:

1. Global imports of things like logger and GlobalContext are done through explicit path. Is there some way to do a type of virtual package where these can all be imported from @phoenix/phoenix-framework?

2. Right now it iterates over the plugins directory, but it should be able to import these from anywhere. The optimal setup from a developers perspective is that their custom code can live in a completely different repository. Reaction solved this with having npm packages but this was always a difficult solution as it involved either publishing packages to your own private npm or github, or using something like pnpm to have "virtual" packages.

Should spend some time looking at what other people are doing since this is a pretty critical feature. At some point will probably involve publishing a package that can be imported from and that each plugin just needs to call a "register" function.

[brent-hoover]

I am going spend a little more time investigating what other frameworks do but I think the approach will be essentially what we ended up with RC.

We create an cli app that can:

1. Create a skeleton app
2. Create an example app (this will be our commerce app)
3. Skeleton out a plugin

The framework package will import a "register" function that they will pass everything into (models, etc). In each app will be a pluginloader that iterates over all the plugins and calls their index and in the index they will call the register function. This will be like the 25 line loader in the RC app so none of that logic lives in the app, but in the framework

Possibly I can use my work on the RC cli app.

Also it's going to be time to think of a better name for the package than phoenix-framework although I suppose while no one is using it it doesn't really matter

Not sure what makes the most sense if we want to go with a monorepo approach and have both the cli app and package in this repo or if it's just simpler to keep them separate. Again, I will spend a little more time investigating what other people are doing.

[brent-hoover]

I notice that Adonis just uses npm init to init a project rather than having to install a cli. Also I noticed that expressoTS also is Bun compatible.

[brent-hoover]

@aldeed This is the thing I will work on next, would like to get your thoughts

Also any thoughts on how to best structure the repo to possibly keep the CLI, the template app and the main framework that will be published as a package all in the same repo?

Also might want to move the Event System and the RBAC to separate plugins