[components] For https://github.com/mozilla-mobile/fenix/issues/17816: add Action...

[components] For https://github.com/mozilla-mobile/fenix/issues/17816: add Action.IMPLEMENTATION_DETAIL in Facts.

After discussing with Sebastian, we decided it might be good to add
Profiler markers via Facts rather than the main alternative which was
calling the Profiler API directly. We thought so for the following
reasons:

1. we don't know what profiler markers are useful so we want to be able
to iterate quickly. Adding dependencies on the Profiler and landing
these changes across two repos hinders that
2. we want to instrument the code as close to specific method calls as
possible (e.g. GeckoSession.loadUrl) but it's not always easy to do so
(e.g. in the previous example, passing a Profiler reference to
GeckoEngineSession is difficult because GES is not a global dependency)
3. we can only add Profiler markers from the main thread so adding
markers will become more difficult if we have to understand the
threading needs of each Profiler call site

An additional benefit with having this infrastructure is that it's easy
to add Profiler markers for local debugging.

The downside with the Fact approach is that it's less explicit and our
tools would be less effective at modifying that code (e.g. refactors).

That being said, if we find a location where it would be valuable to
have a long term Profiler marker, we should consider instrumenting it
via the Profiler API.