Add doc and test for Container's hitTest behavior

[dkwingsmt]

Description

A lot of people use Container as a hit test target. This PR adds docs and tests for container's hit test behavior.

Related Issues

• Raised by GestureDetector with empty Container as a child is not tappable  #49919
• We plan to make hittesting transparent Container an assertion (Assert if a transparent container absorbs hits #51000)

Tests

I added the following tests:

• Container is hittable if and only if it has color or any decorations

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I signed the CLA.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I updated/added relevant documentation (doc comments with ///).
• All existing and new tests are passing.
• The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
• I am willing to follow-up on review comments in a timely manner.

Breaking Change

Did any tests fail when you ran them? Please read Handling breaking changes.

• No, no existing tests failed, so this is not a breaking change.

[dnfield]

I think this is true, but it's a little bit difficult to parse. Maybe

By default, containers return false for all hit tests. If the [color] property is specified, the hit testing is handled by [ColoredBox], which always returns true. If the [decoration] or [foregroundDecoration] properties are specified, hit testing is handled by [Decoration.hitTest], which also always returns true.

It's a little unsettling to be documenting such behavior of other widgets, but I don't see how that could change without some kind of break anyway at this point.

[dkwingsmt]

I don't think it's fair to say Decoration.hitTest always returns true, since the subclass will very likely override it, such as in ShapeDecoration.
Other than that, I've updated the doc. Thanks for the suggestion.

[dnfield]

uber nit: this looks a little weird in widgets, I guess it's so you can use Colors? I have a vague hope that someday we could run tests based on what they import, and things like this will probably have to be rewritten. But it happens elsewhere, it's ok to leave for now.

[dnfield]

LGTM

[goderbauer]

(PR triage): @dkwingsmt is this one ready to go?