The mocked context.db update function would try to call map on an
object, which will fail. The intention was to replace the column values
with the original ones. It's sufficient to directly print the input
instead instead.

Recently, we erroneously encountered "Delete" lifecycle transitions. One
suspect is RPC responses from the registry contract incorrectly being
parsed as `None`. This PR logs any RPC response interpreted as `None` so
we can confirm if this is the culprit.

UI Changes after jam session with Xuan

All logic associated with the creation of the context object resides
inside the Indexer class, which bloats the file and complicates unit
testing. In addition, it prevents access to the context object itself so
that these calls can be made through the Indexer class itself.

This PR refactors this logic into its own class, allowing access to
context methods through Indexer. The object is still recreated each time
it is accessed as the object bakes in some state information (block
height and log entry array) which need to be updated on subsequent
accesses.

I've also reorganized the folders so that we have fewer folders under
src as it is getting cluttered.

wizard code is wrapped with default header

This PR updates provisioning such that user-related errors are written
to the user-owned logs table, allowing them to debug issues with their
schema.

Logging to the user table is tricky, since this table is created
_during_ the provisioning step itself. Therefore, I have split
provisioning in to two phases:
1. System Resources - Setups up system related entities: database,
schema, logs table/jobs etc.
2. User Resources - Applies user schema, configures Hasura etc.

This separation allows us to isolate the tasks which are likely to fail
due to user error, and therefore only surface errors which are relevant.

The creation of the logs table _should always succeed_, if it doesn't
there is something wrong with the system, i.e. some form of bug has been
introduced. Errors thrown during the System portion of provisioning will
be error logged to the machine, and I will tune the existing alert so
that we are notified of these errors.

Additionally, I have converted all non-critical error logs to warnings,
so that we don't get alerted on non-issues.

closes: #901

I added a little bit more logging to the lifecycle state changes, as
well as renamed the `Stopping/Stopped` states to `Suspending/Suspended`
states to more accurately capture the intention.

closes: #977

types are now generated for launchpad code

consolidated 2 checkboxes 'select all' and 'unselect all' into a single
checkbox. Default is checked. Onclick would uncheck and subsequent
clicked woud do vice versa.

all removed files:
```
DiffEditorComponent.js
MonacoEditorComponent.js
resize.js
block_details.js 
```
refactored ResizableLayout to house the functionality in a reusable dp.
Results are some absurdly fast transitions between tabs.

New [Resizable Editor
File](https://github.com/near/queryapi/blob/f00ab7dc8fa65199a40de1b638970479760b6bfe/frontend/src/components/Editor/EditorComponents/ResizableLayoutEditor.jsx)
Encompasses logic from
**MonacoEditorComponent**,**DiffEditorComponent**, **ResizableLayout**,
**ResizeableLayoutEditor**

Upon refactoring resizable (resize.js), and block_details.js were
removed as there are no real functionality used around them.

Provisioning is occasionally finnicky, failing on different parts of the
process. Having retryable provisioning allows us to heal indexer state
through retries rather than manually actioning this. To this, the
provisioning step needs to have access to accurate status of
provisioning in order to make the correct decisions on which
non-idempotent actions to take.

This PR introduces a ProvisioningState class which represents the status
of provisioning, and can be used to make decisions on what parts of
provisioning need to be completed.

This PR moves the synchronisation logic within
`ExecutorsHandler`/`BlockStreamsHandler` in to `LifecycleManager`. The
motive behind this is to provide greater awareness/control over the
individual sync tasks (managing unhealthy, reconfiguring, etc.) to
`LifecycleManger`.

I plan to build on top of this in my next PR, and have
`LifecycleManager` count how many times an unhealthy stream/executor was
restarted, and move the Indexer to `Suspended` if it goes above a
configured threshold. This refactor makes "counting" actually possible.

Wanted to land the refactor PR first to make review easier.

The existing Hasura config is used for setting up the shared logs/state
tables. This is no longer needed and complicates the setup of QueryAPI,
therefore I'm removing it.

As QueryAPi is being decommissioned, this PR adds a note to the frontend
and a link to the documentation, where we can provide additional
details.

<img width="1519" alt="image"
src="https://github.com/user-attachments/assets/3eafa001-e71e-48ef-9c89-e38ea5330b64">