Generate public API layer

[erikrose]

Strawman:

Generate a top-level module within fastly_compute for each of the interfaces in wit_world.imports. Import the whole contents of the latter in the former, and the former becomes our public API.

If we want to expose the componentize-py-generated stuff directly to the public, we can. If we change our minds in a backward-compatible way, we can replace an item in, say, fastly_compute.acl with a nicer one of the same name, hiding the wit_world one behind it. Even class comparisons using isinstance() should continue to work, since all the customer ever got ahold of as a comparand was the public import path.

The machinery made for #30 can handle the generation fairly easily.

But: how ergonomic is the straight wit_world stuff? Are we going to want to paper over all of it anyway? I have not yet looked it over with that in mind.

[erikrose]

Perhaps a sys.path hack would suffice for unmodified interfaces, but could an IDE follow it? Are LSPs using static analysis or loading up Python and actually importing things?

[erikrose]

I don't think it's necessary to do this before public release—or perhaps at all.

1. It may be that we end up putting a layer in front of everything. We found it fruitful even for something as simple as ConfigStore.
2. The WIT is now stabilized (v0.1.0), so customers can go poking at the raw WIT API if they like. It doesn't put us in a bind because we can't change it backward-incompatibly anyway.
3. If the customer wants a feature from a newly introduced abstraction layer, they can update their code, which they'd have to do anyway to take advantage of most conceivable improvements.

[posborne]

With #84 I took the approach of generating a layer of code to replace monkeypatching and which solves a few issues and chooses (pending discussion) to daylight this _bindings layer as a public API surface.

While remaining at alpha/beta support level and potentially long-term, I think have this level of abstraction available (with a few exceptions) provides more value than harm and gives us a fairly consistent way to override/add/remove methods as needed. I think having slightly less ergonomic but usable interfaces that target a stable ABI is probably fine, even if we will likely choose to break some of these APIs with future updates (or provide 2nd-level abstractions in addition).