fix: crash when decompiling framework-res.apk with a tag (regression)

[IgorEisberg]

This fixes a regression since 2.8.0 that causes apktool to crash when decompiling framework-res.apk (which has no other framework dependencies) with the -t tag option:

$ java -jar apktool.jar d -f -t mytag framework-res.apk -o framework-res
I: Using Apktool 2.8.1-SNAPSHOT on framework-res.apk
I: Loading resource table...
I: Decoding AndroidManifest.xml with resources...
I: Regular manifest package...
I: Decoding file-resources...
I: Decoding values */* XMLs...
Exception in thread "main" java.lang.NullPointerException
        at brut.androlib.res.ResourcesDecoder.decodeResources(ResourcesDecoder.java:247)
        at brut.androlib.ApkDecoder.decode(ApkDecoder.java:98)
        at brut.apktool.Main.cmdDecode(Main.java:190)
        at brut.apktool.Main.main(Main.java:93)

This is caused by the fact that mApkInfo.usesFramework is null if there are no framework dependencies for a given APK (which is true for any base framework, i.e. framework-res.apk), and then doing mApkInfo.usesFramework.tag = mConfig.frameworkTag; in ResourcesDecoder, causing a NullPointerException.
How wasn't it caught during development? Perhaps due to the previous framework loading regression that recently got fixed, that loaded frameworks with arbitrary IDs, which caused UsesFramework to always be created because ids array was never empty, even when it should have been.
And so:

1. There is no good reason not to always create a UsesFramework object, regardless of content.
2. There is no good reason to set the tag in ResourcesDecoder.decodeResources rather than ResTable.initApkInfo that has reference to the Config object as well.
3. There is also no need for null-checking mConfig.frameworkTag, because if it's null then info.tag (which is already null by default) will simply be set to null again.

[iBotPeaches]

thanks. appears my smoke test of decoding a basic framework failed since I didn't use -t