Tight coupling of Quark Script API

## Describe the issue

Hi guys, when I implement the new Quark Script.
I found out that `quark/script/__init__.py` has 3 tight coupling classes, `QuarkResult`, `Behavior`, and `Method`.

I believe the Quark Script API is supposed to design like LEGO,
which can be used independently but is also compostable.
See the example below.


Use Quark analysis to get `QuarkResult`.
The `QuarkResult` contains multiple `Behavior` in `behaviorOccurList`.
Each `Behavior` contains multiple `Method`. For example, `firstAPI` and `secondAPI`.

The idea is intuitive like a car contains an engine, and an engine contains screws.

However, I found out the `QuarkResult`, `Behavior`, and `Method` has instance of each other.
For example, `Method` has `QuarkResult` and `Behavior` instance. See the codebase [here](https://github.com/quark-engine/quark-engine/blob/852c2663be45093f3ef61feaf390f716ef9f8e53/quark/script/__init__.py#L87-L100) or code block below.
```python
class Method:
def __init__(
self,
quarkResultInstance: "QuarkResult" = None,
methodObj: MethodObject = None,
quark: "Quark" = None,
behavior: "Behavior" = None,
targetMethod: "Method" = None
) -> None:
self.quark = quark
self.quarkResult = quarkResultInstance
self.innerObj = methodObj
self.behavior = behavior
self.targetMethod = targetMethod

...
```

Same issue in the `Behavior` class. The Behavior has `QuarkResult` instance. See codebase [here](https://github.com/quark-engine/quark-engine/blob/852c2663be45093f3ef61feaf390f716ef9f8e53/quark/script/__init__.py#L219-L234) or code block below.

```python
class Behavior:
def __init__(
self,
quarkResultInstance: "QuarkResult",
methodCaller: Method,
firstAPI: Method,
secondAPI: Method,
) -> None:
self.quarkResult = quarkResultInstance
self.methodCaller = methodCaller
self.firstAPI = firstAPI
self.secondAPI = secondAPI

self.methodCaller.behavior = self
self.firstAPI.behavior = self
self.secondAPI.behavior = self

...
```

According to Wikipedia, the tight coupling could be 3 disadvantages:

> 1. A change in one module usually forces a ripple effect of changes in other modules.
> 2. Assembly of modules might require more effort and/or time due to the increased inter-module dependency.
> 3. A particular module might be harder to reuse and/or test because dependent modules must be included.

**In a nutshell, it is difficult to modify, maintain, and unusable.**

## Possible Solution

To solve the tight coupling, we must redesign and refactor the Quark Script API based on a design pattern.
The design pattern will be our principle of design.

However, we will need to modify the Quark Script in the document.
If we update the Quark Script too often, that may confuse the user.

One of the mitigation is to create a new module, `quark/script/api.py`, for a new design of Quark Script API.
And keep the old one, `quark/script/__init__.py`, until we fully complete the new API design.