In Python, two types that are nested inside the same other class
couldn't inherit from each other; the type references were rendered
incorrectly.

Specifically, the following:

```ts
class A { }

namespace A {
  interface B { }
  interface C extends B { }
}
```

Would produce could that doesn't compile correctly. It turns out that
the referencing rules are different during the initialization of
classes:

```py
class A:
    class B: pass
    class C(B):                         # <-- short
       def some_method(self, b: "A.B"): # <-- long (in strings)
          return A.B()                  # <-- long
```

This PR fixes that, and introduces some simplifications and refactoring
of the type handling code along the way:

- Reversed the order of 2 code blocks in the `UserType.pythonType()` function, to
  consistently structure the code as "early exit" paths (`if
  (weird_condition) { return ...; }`). This makes the diff bigger,
  sorry, but the long-term maintainability of this code better (imo).
- Moved the implicit `typeAnnotation?: boolean` property of the naming
  context to an explicit parameter of the rendering function
  `pythonType()`.
- We now distinguish 3 ways of rendering types: as type annotations,
  as values in methods, as values during class initialization.
- Strictly render all type annotations using quotes. This always works
  and is simpler: it used to allow us to get rid of `emittedTypes` which
  tracks types we should emit quotes for and types which we can
  reference directly... but there are no benefits to direct references,
  so why would we?