Activity start: Send featureId from context->AppOpsManager

The expected usage pattern for noteOp is to get the
Context#getOpPackageName() and Context#getFeatureId() in the calling app
and the call

noteOp(callingPackageName, Binder.getCallingUid(), callingFeatureId)

As the featureId parameter is new this parameter has to been piped all
through from the ...Manager classes running in the app all way deep into
the bowels of the system server.

There is a special featureId==null for the "default" feature. This is
used in two cases:
- In case the system server (packageName == null || packageName ==
  "android") makes a call
- In the case there is no caller. In this case I left annotations in the
  code to make clear that the default feature is used

Raw binder interfaces (defined in AIDL files) are not supposed to be
used by apps. Still historically this has happened and we ended up with
@UnsupportedAppUsage tags in these files. Also AIDL does not support
two methods with the same name but different parameters. I.e. in the
case when I had to add a paramater to a method tagged as UnsupportedAppUsage I
- created a new method ...WithFeature with the additional paramter
- set a maxTargetSDK for the old method and mention the public API to
  use in the deprecation method
This is really not pretty. Once there is no more app using the old
internal API this hack can be removed.

Additionally this change removed all internal calls to
AppOpsService.noteOperation and AppOpsService.checkOperation and
replaces them with the public API equivalent. This sometimes means to
move the resolution of the mAppOpsManager to be lazy.

Exempt-From-Owner-Approval:: Just piping through arguments
Bug: 136595429
Test: atest --test-mapping frameworks/base/services/core/java/com/android/server/am/
      atest CtsAppOpsTestCases added test to cover activity start
      atest WmTests
Change-Id: Ic7056b492cb1c9a79158e6c2b4864898a0eb5b2a