improvements: refactor to be able to support non-cosmos chains

# Redefining Primitives for Starship to Support Multiple Chains
## Overview
The current design of Starship is centered around supporting cosmos chains. As the project aims to expand its capabilities to support more types of chains (starting from issue #155), it becomes necessary to redefine some of the core components used in Starship. This proposal outlines the key changes needed to achieve this goal, including introducing a kind field in the configuration, defining testing procedures for non-cosmos chains, handling chain expansion, and managing Docker images for new chains. Additionally, other services and toggles, such as explorers and registry, will also be addressed.

## Proposal: Introducing kind of Chain
### chains
To enable support for different types of chains, we propose introducing a new field called kind in the configuration file. This kind field will signify the ecosystem to which a particular chain belongs. Here's an example of how the configuration would be updated:

```yaml
chains:
- name: osmosis-1
type: osmosis
kind: cosmos
...
- name: eth-4
type: eth
kind: ethereum
...
```
The kind field will be crucial as Starship expands, allowing for easy categorization of chains based on the ecosystem they belong to.

### relayers
Relayers is something that can remain the same. Since relayers are running between 2 chains, ecosystem or `kind` keyword wont matter.
```yaml
relayers:
- name: new-bridge
type:
chains:
- osmosis-1
- eth-4
```

### explorers
Same for explorers, the kind of explorers should inherit the `kind` of ecosystem it operates in

> Note: There could be additional directives that are ecosystem specific, that might need to be spun up or handled seperately. This might cause directives to be ecosystem specific. (non-ideal)

## Other feature toggles and paradigms
As part of this expansion, we need to redefine additional toggles, services and paradigms to accommodate different ecosystems. This includes:

1. **Testing of Non-Cosmos Chains**: To support non-cosmos chains, we'll need to establish different types of tests tailored for each ecosystem. The details of these tests and the testing framework will be defined in the documentation.

2. **Addition of new ecosystems**: We should outline a clear process for adding new kinds of chains to Starship. This process will include guidelines on adding support for new ecosystems, configuring chain-specific parameters, and ensuring proper integration.

3. **Docker Images for New Chains**: As new chains are introduced, Docker images will need to be created for each chain to facilitate deployment. Documentation and guidelines should be provided for maintaining and managing these images.

4. **Other Services and Toggles**: The proposal mentions explorers and registry as additional services. Further details should be provided on how these services will interact with different chains and how they can be toggled based on the chain's ecosystem.

## Alternative Proposal: Separate Helm Charts per Ecosystem
An alternative approach to consider is the introduction of separate Helm charts for each ecosystem. This would involve having dedicated configuration files for individual ecosystems. Although these ecosystems reside in the same Kubernetes cluster namespace, communication between them can be facilitated through environment variables within the cluster or via a shared registry service acting as a central point of entry.

> Note: The proposal acknowledges that interchain bridges or relayers might pose challenges when passing information across ecosystems.

In this alternative approach, each ecosystem will have its own configuration and initialization process using specific Helm charts, tailored to the unique requirements of that ecosystem.

## References
To support the implementation of this proposal, the following references may prove useful:
* [Helm Chart Dependencies](https://levelup.gitconnected.com/helm-data-sharing-between-parent-and-child-chart-c4487a452d4e)
* [Helm Tests](https://helm.sh/docs/topics/chart_tests/)
By incorporating these changes and considering the alternative approach, Starship can be redefined to efficiently support various blockchain ecosystems, ensuring a robust and extensible platform for the future.

## Conclusion
Currerntly both the approaches seem to have some caviates. A clean solution with seperate helm chart is currently what seems to make most sense. But more edge cases needs to be cleared out.