Make it clearer where Tilt file watch rules come from

This request stems from #2169, where @kevin-lindsay-1 writes:

To me the product answer would be to make it clear which file(s) triggered an update in the UI, and where that particular inclusion or exclusion rule came from, and allow overrides. I should be allowed to shoot my own foot, but it should be obvious when I'm using it who is shooting my foot (me or tilt).

I don't have an issue with tilt having reasonable defaults, however I just don't want it to do magic that I could only discover via reading the "correct page" in the docs, and I always want to be able to control it at the end of the day.

Can we make it clearer where Tilt build context and file watch rules come from? There could be opportunities in Tilt's documentation, in build / live_update logs, and in the API.

The filewatch API gives detailed information about watch and ignore paths, but information related to the files excluded from the build context is more challenging to inspect through the API:

tilt get -ojsonpath="{.spec.contextIgnores}" dockerimage <image-name>

Start with the file_changes.html sections on where file watches come from and inspecting file watches, then examine the documented dockerimage contextIgnores query. Compare what the API exposes with the requested build/live_update log and documentation improvements; done means the source of build-context and file-watch rules is clearly inspectable.