The `CodeInfo` type is one of the oldest types in the system and has
grown a bit of cruft. In particular, the `rettype`, `inferred`,
`parent`, `edges`, `min_world`, `max_world` fields are not used for the
original purpose of representing code, but for one or more of (in
decreasing order of badness):

1. Smuggling extra results from inference into the compiler
2. Sumggling extra arguments into OpaqueClosure constructors
3. Passing extra information from generated functions to inference

The first of these points in particular causes a fair bit of mixup
between caching concerns and compiler concerns and results in external
abstract interpreters maintainging their own dummy CodeInfos, just to
comply with the interface. Originally, I just wanted to clean up that
bit, but it didn't really make sense as a standalone piece, so this PR
is more comprehensive.

In particular, this PR:

1. Removes the `parent`, `inferred` and `rettype` fields of `CodeInfo`.
They are largely vestigal and code accessing these is probably doing the
wrong thing. They should instead be looking at either the CodeInstance
or remembering the query that was asked of the cache in the first place.

2. Makes `edges`, `min_world` and `max_world` used for generated
functions only. All other uses were replaced by appropriate queries on
the CodeInstance. In particular, inference no longer sets these. In the
future we may want to consider removing these also and having generated
functions return some other object, but that is a topic to revisit once
the broader compiler plugins landscape is more clear.

3. Makes the external type inference interface return `CodeInstance`
rather than `CodeInfo`. This results in a lot of cleanup, because many
functions had multiple code paths, some for CodeInstance and others for
fallback to inference/CodeInfo. This is all cleaned up now. If you don't
have a CodeInstance, you can ask inference for one. This CodeInstance
may or may not be in the cache, but you can look at its types, compile
it, etc.

4. Moves the main inference entrypoint out of the codegen library. There
is still a little bit of entangelement, but this makes codegen much more
of an independent system that you give a CodeInstance and it just fills
in the invoke pointer for.

With these changes, only the third use of the above mentioned fields
remains.

The overall theme here is decoupling. Over time, various parties have
wanted to use the julia compiler with custom IR datastructure, backend
code generators, caches, etc. This doesn't quite get us all the way
there, but makes inference and codegen much more independent with a
clear IR-format-independent interface (CodeInstance).

---------

Co-authored-by: Valentin Churavy <v.churavy@gmail.com>