Streamline usable as a "tool" for an arbitrary repo/PR

Somewhat relates to #162 as that one to expose API to fetch logs for specific commit (PR).

While working on a feedstock repo, I realized that what I would have loved to be able to just request all logs for my now failed PR. Establishing config etc is like asking to duplicate data given my current situation -- all of it might be deduced
- I am in a feature branch which has default *remote* associated so I can get github URL, know the branch
- from that *remote* I can figure either it is a fork - if fork, get *upstream* github repo
- discover PR on *upstream* repo which has my PR/commit
- fetch all the logs for which I find CI having ran anything

- I might not be able or want to modify the repo with `tinuous` configuration file.
- I would not care much about paths, i.e. some sensible default would be good enough

### Idea:

If no config file given:
- if `tinuous` doesn't find `tinuous.yaml` can assume `.git/tinuous/config.yaml` to be the default location (`.git/` is autodiscovered for a repo) if no config file is provided
- `tinuous bootstrap-config` command would discover relevant details and create config in the specified on CLI or the default (above) location

- add `tinuous fetch-current-pr` command (so #162 is relevant).

Then in any given repo I could just `tinuous bootstrap-config && tinuous fetch-current-pr` to get a copy of all the logs for the PR and investigate them without establishing "full blown" archive of logs like we do for our tools. Any other time in any other PR later on I could just `tinuous fetch-current-pr` and get a copy of relevant logs

WDYT @jwodder ?

Review the existing CLI handling for config discovery, repository remotes, pull-request lookup, and CI log fetching. Define how bootstrap-config and fetch-current-pr should work without a repository configuration file, including their default paths and fork handling. Done means the proposed workflow can discover the current PR and retrieve its available logs in an arbitrary repository.

Written by the indexing model from the issue text.