Refactor @loopback/context to allow applications to define BindingScopes instead of hardcoding them.

[Salketer]

I'll start with the first line of the package's readme:

This module provides facilities to manage artifacts and their dependencies using Context in your Node.js applications. It can be used independent of the LoopBack framework.

This means other applications need to abide to the currently set BindingScopes even if they don't exactly fit their needs. This also makes things complicated to add scopes in a loopback application.

I think we could ease the use of the context package by allowing the creation of scopes and making it more obvious to create a "scope" context.

// Create a scope that can be used
export const RoomScope = BindingScope.create('Room');
// Create my scoped context
export class Room extends Context{
    constructor(ctx:Context){
       super(ctx,RoomScope);
    }
}
// OR simply
const myContext = new Context(parent,RoomScope);
// Make a service available in my scope
@injectable({scope:RoomScope})

The context name would be derived from the Scope's name. Also, I think it would be a good idea to check if an ancestor of the context being created is of the same scope to error out.

The current loopback BindingScopes would be easily defined by the core package as to be able to still use them and be backward compatible since the SERVER and APPLICATION contextes are pretty simple. I think that SINGLETON and TRANSIENT/CONTEXT should come out of the box tough. And for REQUEST, since it is falling back to TRANSIENT when not present, the best would be to simply allow for an "optional" property in the BindingScope like so: const REQUEST = BindingScope.create('request',{optional:true}); which would basically try to find the scope in the ancestors and fallback to the current context if not found.

I think that the changes would easily go unnoticed from most people using loopback, but would allow great extension of the capabilities an app could have.

Some use cases I have personally faced:

• Group users into a lobby for a multiplayer game, and easily access game related resources. Currently a provider is used to provide the right lobby instance from a cached Map. Instances do not use DI, they are instantiated with everything they will/might need.
• We have built a webdav server around loopback, a lot of caching would have been easily done by having a context per user instead of saving huge maps on the server context.
• A standalone game server that uses @loopback/context for DI. There's no APPLICATION, we could maybe re-use SERVER, there is no REQUEST but some other levels. In this case we are looking to inject a different class for the same binding key depending on the scope (player-controlled vs ai-controlled actors).