Users confused when Prout ignores PRs that don't touch configured folders

At the moment, Prout only interacts with PRs that touch folders within the project that are next to, or below, a `.prout.json` config file. This makes sense, because the project might contain many other folders that end up getting deployed to other destinations- that might have other checkpoints, or no checkpoint at all.
##### Multi-folder support?

This PR didn't touch the `dashboard` folder (only `shared-lib/src/...`), and so was correctly ignored by Prout: https://github.com/guardian/ophan/pull/1265/files - but code in `shared-lib/src/...` _does_ end up deployed to the Ophan Dashboard, so it _would_ be nice to know about it being seen at that checkpoint.
##### Diagnostics?

It would also be good to have an authenticated endpoint that users can look at to see how Prout regards their project (what is the status of the PRs? which folders is Prout watching?) - any user with push access to a given repo should be able to see that information. Timing attacks in establishing that?! Shouldn't be an issues so long as we are just initially validating the user has push access to the repo, and _then_ checking that it's on Prout's whitelist.

cc @philwills

Start by tracing how Prout discovers `.prout.json` files and filters pull requests by watched folders, using the `dashboard` and `shared-lib/src/...` example as a reference. The issue also proposes an authenticated diagnostics endpoint, so first establish whether multi-folder support, diagnostics, or both are in scope; done requires an agreed design and tests for the selected behavior.

Written by the indexing model from the issue text.