refactor: internal getKaboomCtx and getInternalCtx, modulizate components

[lajbel]

Okay, this is my new modulization idea

Because some components have to access to internal api (app, gfx) etc, I propose the following

getKaboomCtx()
getInternalCtx()

getKaboomCtx() gets the context from the global scope (the defined ctx variable) in kaboom.ts, with also the option of get the context from this.

For example, in a component

function sayHi() {
    // if is using multiple instances, will use this instance ctx
    const k = getKaboomCtx(this);
     
    return {
        hi() {
            k.debug.log("hi")
        }
    }
}

getInternal should work for the same, but the internal apis are not exported to any place, so it works as an array of internal contexts linked to the kaboom context, and when you use getInternalCtx, it finds the element with the context

function sayHi() {
    const k = getKaboomCtx(this);
    const internal = getInternalContext(this);
     
    internal.getViewportScale();
    
    return {
        hi() {
            k.debug.log("hi")
        }
    }
}

Let me know what do you think, for now I was trying to mantain compatibility with multipleboom example, so I think there's no breaking changes.

[cemalgnlts]

This line doesn't look very nice. It can be tiring to convert the object to an array and check the keys one by one each time. If a component is added and removed frequently, this process will be repeated each time.

[lajbel]

Yeah, maybe only check obj["loadAseprite"]

[cemalgnlts]

Is this what you mean by context?

const k = kaboom({ global: false }) // One context.
const a = kaboom({ global: false }) // Another context.

[lajbel]

Is this what you mean by context?

const k = kaboom({ global: false }) // One context.
const a = kaboom({ global: false }) // Another context.

Yes!

https://kaboomjs.com/play?example=multiboom

[lajbel]

I changed more things, adding _k variable to KaboomCtx, this means future internal api (for now only getViewportScale) stuff will be exposed to the user.

In return, it is not necessary to use Array.find to get the internal api to be used in other files.

I don't know if it's a good thing to export the internal api, I'm thinking about the possibilities for plugin creators. But beyond that, does anyone have an opinion?

[cemalgnlts]

Good work, it looks better now. I have no idea at the moment what to do to make it better. Maybe this pull request can stay a little more open.