Add App.from_name for construction of a lazily-hydratable App

[mwaskom]

Describe your changes

This PR adds a new App.from_name method with similar lazy construction semantics to other .from_name methods on Object subclasses, along with an App.hydrate method for on-demand hydration. The intention is to make it possible to deprecate App.lookup when we deprecate other Object.lookup methods, streamlining object construction onto a single lazy path.

As App is not a subclass of Object we face a decision about whether we should make it one (and leverage the existing hydration plumbing) or add some App-specific plumbing. This PR takes the latter approach, which feels more straightforward now without foreclosing on adapting the other approach later.

There's definitely some confusing things here. I've made it so that you can't call App.hydrate if you instantiated an App by calling its main constructor (App(name)). Potentially we will want to leverage lazy-hydration of the App layout when we do App redeployments (i.e. the current _init_local_app_existing). I think we can punt on that as there are not currently any user-facing workflows where you would want to hydrate the App and then access its layout, but we've tlaked about it, e.g. for Function discovery after looking up a deployed App.

Part of CLI-96

Backward/forward compatibility checks

---

Check these boxes or delete any item (or this section) if not relevant for this PR.

• Client+Server: this change is compatible with old servers
• Client forward compatibility: this change ensures client can accept data intended for later versions of itself

Note on protobuf: protobuf message changes in one place may have impact to
multiple entities (client, server, worker, database). See points above.

---

Changelog

• Added a new App.from_name methods for lazily constructing an App based on a lookup and an App.hydrate method for hydrating it with server metadata on demand. These methods should be used instead of the eager App.lookup method, which will be deprecated soon (along with other .lookup methods). Note that App.from_name is primarily useful when you need an App to associate with a modal.Sandbox; other use-cases should continue to create Apps via the main constructor (app = App(name)).

[erikbern]

super minor but this could maybe just be a constructor argument

[mwaskom]

I’m fairly averse to “private parameters” in public interfaces: best case, you confuse users or at least present them with information they don’t need to think about, worse case they try to use it and end up in trouble somehow.

[mwaskom]

I’d really prefer to just merge __init__ and .from_name but couldn’t see a simple way to do that.