Fix documentation that seems to imply `baseUrl` does something it doesn't

[RyanCavanaugh]

    > If you get tired of imports always looking like "../" or "./", or needing to change them as you move files, this is a great way to fix that.

This text is one of my biggest pet peeves in the documentation. It's described as if it's some convenience feature that TS will take care of for you, but in reality it only works if your runtime environment also understands it, because TS emits the import paths you use verbatim.

Originally posted by @fatcerberus in #51260 (comment)

[fatcerberus]

There are similar implications in the docs for paths, for what it’s worth.

[MAYANKpandey14]

I think it implies creating a tsconfig.json file with the following contents:

  "compilerOptions": {
    "baseUrl": "./modules"
  }
}

So if a module is imported such as navBar it would be looked up in ./modules/navBar
import A from navBar

Although, what you are pointing out is correct and the use of baseURL can be explained more precisely and not in a way it is done already.

[andrewbranch]

Why does baseUrl actually exist? Today, it could legitimately be useful for doing ESM in the browser, though we lack nearly every other option necessary to support that scenario. But I’m pretty sure baseUrl was made long before ESM in the browser was possible, or even a definite future. Was it made to pair with AMD?

[RyanCavanaugh]

Right, it's named after the RequireJS option which kinda does the same thing: https://requirejs.org/docs/api.html#config-baseUrl