Snap builds should support dynamic branches

I have a project in github that is packaged as a snap. The project itself is complex and consists of many components, which makes it difficult to run from source for non-developers. One of the ways we get more people to review pull requests is that we build each one as a snap and put it into a branch dedicated to that specific pull request. This works quite well, but it's currently a manual process which doesn't scale well: we push to a branch in Launchpad with an associated snap, request the snap be built for all supported architectures and automatically uploaded to the store with no branch, then we visit the dashboard to determine which revisions were uploaded and manually call `snapcraft release` to put them into a new branch for the pull request.

This could of course be easily automated with e.g. Circle CI, but then we'd be limited to amd64, and we'd like our arm users to be able to test the pull requests as well.

I'd like to be able to request that Launchpad build a snap and publish it straight into a specific branch (one that changes depending on pull request). I can sort of hack this behavior by creating a snap recipe on LP associated with a specific branch, force-push to that branch from the CI for the pull request, and then use the LP API to set the store_channels for that snap and trigger the build. However, that doesn't scale well when considering the possibility for multiple simultaneous pull requests, because I assume the store_channels only apply once the snaps complete building.

In an ideal world, I could do the following with the only prereq being that I have an LP account associated with the snapcraft Dashboard with permissions to publish the snap in question:

1. Use the LP API to say "I want to build a new snap. It should use <this git/bzr repo URL branch that contains a snapcraft.yaml>, <this> archive, <this> arch series, and <this> pocket."
2. Take the object created in (1) and say "Please build this snap for <these> architectures, and when done, publish them into <this> channel (which may include a track, risk, and/or branch)." Bonus points if I could say "<these> channels" to support releasing to both the latest track as well as the versioned track.
3. When the build and publication are complete (assuming no error), the LP account should not be littered with temporary snap recipes.

My world doesn't have to be ideal, of course, but it'd be nice to support this type of use-case somehow.