Enhance the Nimbus Script and rewrite parser

[Tiagoperes]

Features currently missing in Nimbus Script that must be implemented

1. Object literals

Nimbus script doesn't support the symbols {and } to create an object. Today, an object can only be created with the operation object (example: @{object('a', 1, 'b', 2)})creates the object{ a: 1, b: 2 }`.

The Nimbus Script should recognize expressions like: @{{ a: 1, b: 2 }} as object values (Map<String, Any> in Kotlin).

2. Array literals

Nimbus script doesn't support the symbols [and ] to create an array. Today, an array can only be created with the operation array (example: @{array('a', 1, 'b', 2)})creates the array['a', 1, 'b', 2]`.

The Nimbus Script should recognize expressions like: @{['a', 1, 'b', 2]} as array values (List<Any> in Kotlin).

3. Dynamic object access

Nimbus script access a key of an object by using the .(dot) operator. Example: person.name. This is fine for most cases, but not enough if:

(1) the property we want to access has unexpected symbols like spaces, "+", "-", ".", etc.
(2) we don't know in advance the name of the property we want to access, it comes from another state.

To solve both issues, we need a different way to access a property of an object, this new way is the bracket syntax, just like Javascript:

To access a property with special symbols:
@{person['-age of_person']}

To access a dynamic property:
@{person[stateHoldingTheNameOfTheProperty]}

This is also super useful for accessing an index of an array when this index is stored on a state:
@{myList[index]}

Problems with the current implementation of the parser

The current parser is a direct translation from Beagle's original parser (written in typescript). When Beagle was built, we needed the feature implemented asap and it has never gone through revisions. Back then we decided for a simpler implementation with some performance drawbacks. These performance drawbacks are much more visible in the Kotlin implementation (specially for Kotlin Native) and must be addressed.

When implementing these new features, we should actually rewrite the code, using only a custom Pushdown Automaton, without regexes.

This is not critical because, despite being a performance issue, it happens only when a screen is initialized, which ends up mixing with the request time.