Updating authentication and token management flow to accomodate context switching of agent for different roles based on type of agent (multi-tenant or dedicated) and different role in multi-tenancy(dedicated and tenant)

• Token creation for different roles (Basewallet (BW), Tenant Wallet(TW), Dedicated agent wallet(DW))
• Authenticating token based on endpoints being accessed and type of token(authorization)
• Attaching agent context based on roles through request
• G̶e̶n̶e̶r̶a̶t̶i̶n̶g̶ a̶n̶d̶ s̶t̶o̶r̶i̶n̶g̶ i̶n̶d̶i̶v̶i̶d̶u̶a̶l̶ s̶e̶c̶r̶e̶t̶ k̶e̶y̶ f̶o̶r̶ e̶a̶c̶h̶ t̶y̶p̶e̶ o̶f̶ u̶s̶e̶r̶ (̶i̶.e̶. D̶W̶, B̶W̶ a̶n̶d̶ T̶W)̶ i̶n̶ t̶h̶e̶i̶r̶ w̶a̶l̶l̶e̶t̶ t̶o̶ g̶e̶n̶e̶r̶a̶t̶e̶ a̶n̶d̶ v̶e̶r̶i̶f̶y̶ j̶w̶t̶ t̶o̶k̶e̶n̶s̶ -
• Secret keys used for generating and verifying tokens for BW and TW in case of multi-tenancy will be same and stored in BW. (Since, opening wallet to access secretKey for each request in case of tenant agent verification will be an expensive process in terms of time and computation) - This is already been coded and only needs to be un-commented depending on which approach we decide on.
• Removing middleware and utilizing authentication module for authorization and context switching
• Handling error for unauthorized access
• Receiving apiKey as an additional parameter while staring the agent. This will act as an authentication for BW and DW
• Releasing agent session at the end of request
• Using agent context from request for all endpoints. (Unlike as a global param currently being used in controllers)
• Update branch
• Optimize in accordance to load-testing reports
• Security: fall back mechanism to update the jwt secret, if required, while starting the agent
• Route changes: to combine didcomm, anoncreds, etc. routes