Improve overrides by co-locating them with original source code

Currently, overrides work by imitating the file structure of the original source code, and replacing the root folder with `overrides`:

- when `mitosis build` processes `src/helpers/foo.ts`, it will look for an override in `overrides/react/src/helpers/foo.ts`

This has a few drawbacks:
- typescript & imports are broken in the overrides files
- overrides are not co-located with what they replace

It would be far better if we add a new syntax to indicate overrides like so:

- when `mitosis build` processes `src/helpers/foo.ts`, it will look for overrides in:
- `src/helpers/foo.react.ts`
- `src/helpers/foo.vue2.ts`
- `src/helpers/foo.vue3.ts`
- etc.

- when `mitosis build` processes `src/components/my-component.lite.tsx`, it will look for overrides in:
- `src/components/my-component.react.lite.tsx`
- `src/components/my-component.vue2.lite.vue`
- `src/components/my-component.vue3.lite.vue`
- etc.

Caveats: JSX runtime types might be finicky for react/solid overrides...but this is still a step in the right direction.

Questions:
- should the suffix extensions be `{target}.lite.{targetExtension}`? the `targetExtension` guarantees that editors perform syntax highlighting correctly and identify the correct syntax, and `target` guarantees that the CLI attributes the override to the correct generator. If we have both `vue2.lite.vue` and `vue3.lite.vue`, then:
- the IDE knows that both are Vue files
- `mitosis build` knows to use one for the `vue2` generator, and one for the `vue3` generator.

Start by tracing how `mitosis build` maps `src/helpers/foo.ts` and `src/components/my-component.lite.tsx` to override paths. Define and test the target-specific suffix rules, including `vue2`/`vue3` and React cases, and confirm the CLI selects the intended generator while editors retain the target extension.

Written by the indexing model from the issue text.