"basic"/"relative" moduleResolution

### 🔍 Search Terms

module resolution, relative paths

### ✅ Viability Checklist

- [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
- [x] This wouldn't change the runtime behavior of existing JavaScript code
- [x] This could be implemented without emitting different JS based on the types of the expressions
- [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
- [x] This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
- [x] This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

### ⭐ Suggestion

Hi all, I am writing a custom JavaScript runtime that only supports module imports using relative paths with file extensions present.

This is akin to browser-based module resolution (minus import maps).

At present, the `compilerOptions.moduleResolution` settings are:
- classic (deprecated)
- node/node10
- node16
- nodenext
- bundler

I think `classic` might work but am hesitant to use a deprecated feature.

Could we include a
```json
{
"compilerOptions": {
"moduleResolution": "relative"
}
}
```

That _only_ permits resolving module import paths that are relative to the current file and requires that import paths include file extensions?

```typescript
import * as foo from "./foo.js" // 👍
import * as foo from "./foo.ts" // 👍

import * as foo from "./foo" // 👎
import * as foo from "foo" // 👎
```

### 📃 Motivating Example

- Browsers using JavaScript modules without a bundler
- Custom JavaScript resolution algorithms
- (shameless plug) https://github.com/alshdavid/ion

### 💻 Use Cases

1. Accurate import semantics for consumers not using Node.js or contexts compatible with Node.js import resolution semantics

Start by reading how the compiler handles the existing classic, node10, node16, nodenext, and bundler moduleResolution options. Trace the compilerOptions.moduleResolution entry point and compare current tests for relative and package imports. Done means a new relative mode accepts extension-bearing relative imports while rejecting extensionless and non-relative imports, with coverage for the requested examples.

Written by the indexing model from the issue text.