working example of iron-session with three protected pages

[jduss4]

Changes proposed in this pull request:

Related to a portion of #22

• adapted the typescript heavy example app from the iron-session repo. They have multiple, I picked this one because it was "recommended" by them and uses the app router.
• currently just a draft PR so we can study it and figure out what we like or don't like

Things to check

• Do the session checks make sense via different methods? Client component vs middleware vs server component?
• Does it make sense how sessions are saved / updated / destroyed?

Also, I'm proactively sorry about the linting errors I'm sure are about to pop up, I can fix them all if we decide we kinda like this code.

Security considerations

None at the moment as this is just a demo app. However, we should consider what this might look like if implemented in our prototype and what additional security considerations we might have.

[jduss4]

This simpler demo offers some good reasoning about why more bells and whistles might be good: https://github.com/vvo/iron-session/blob/main/examples/next/src/app/app-router-client-component-redirect-route-handler-fetch/page.tsx#L68

The session is not updated between tabs and windows. If you login or logout in one window or tab, the others are still showing the previous state

[jduss4]

One thing that would be good to figure out if we were going to explore iron-session further is to figure out how to test if sessions are implemented (and consider how that might vary from this basic example of "username is set" vs a more complicated one of "there's a token and it matches something we're expecting or validates on an API call"), and see if that may change whether we prefer middleware checks vs client / server side etc.

[jduss4]

For now we are not going to worry about encrypting client side session information. @echappen has implemented page protections for logged in user access here: #57