feat: add a middleware integration option

[ge3224]

Implement Middleware Approach for Vite Integration

This PR implements a middleware-style approach for integrating Vite with Go web applications, as discussed in issue #8. The goal is to provide more flexibility and a cleaner separation of concerns while maintaining ease of use.

Key Changes

1. Introduced vite.Middleware as a standalone component, decoupled from vite.Handler.
2. Updated the core logic to support both middleware and handler approaches.
3. Added an example use case demonstrating the middleware integration.
4. Updated documentation to reflect the new middleware approach.

New Features

• vite.Middleware: A flexible middleware component that can be easily integrated with various routing solutions.
• Support for both development and production environments within the middleware.

Example Usage

viteMiddleware, err := vite.NewMiddleware(vite.Config{
    FS:      viteFS,
    IsDev:   *isDev,
    ViteURL: "http://localhost:5173",
})
if err != nil {
    panic(err)
}

mux.HandleFunc("/", viteMiddleware.Use(func(w http.ResponseWriter, r *http.Request) {
    tmpl, err := template.New("index.tmpl").ParseFS(goIndex, "index.tmpl")
    if err != nil {
        panic(err)
    }
    if err = tmpl.Execute(w, nil); err != nil {
        panic(err)
    }
}))

Benefits

• Greater flexibility in how Vite is integrated with Go applications.
• Cleaner separation of concerns between Vite integration and application logic.
• Easier to use with different routing solutions and existing codebases.

Documentation

• Added inline documentation for the new vite.Middleware component.

Backwards Compatibility

This PR maintains support for the existing vite.Handler approach, ensuring backwards compatibility with current implementations.

Feedback and suggestions are welcome. Please let me know if you'd like to see any changes or additions to this implementation.

[olivere]

Sorry for the delay. I'm quite busy during the week, so it'll take some time to review this. It's going into the right direction, but I have to test and feel it first. Thank you so much for pushing this forward.

[tomtomsen]

@ge3224 One thing i noticed, but this could totally be a failure on my end (new to go), is that if i have an error in my handler (i.e. 400 - bad request) and that response does not contain a head, the middleware will fail because it will not found the marker to inject itself.

[olivere]

@tomtomsen Hi there! What do you expect to be a good behavior from this library if you have an error in your handler?

We're experimenting in a slightly different direction. You can follow the discussion in #8 and the PR #10 if you like.