iOS: allow opting out of the private-CoreSVG SVG decoder (exclude_files by default, or an opt-in flag)

### Summary

`ios/SVG/CoreSVG.mm` reaches five private CoreSVG functions via `dlsym`, with the symbol names stored base64-encoded. `SvgDecoder` is then registered app-wide as an `RCTImageDataDecoder` through `codegenConfig.ios.modulesConformingToProtocol`, so this code is linked into and reachable from **every** app that installs the library — including apps that never render an SVG and use SF Symbols for their tab icons.

This is a hard blocker for us, and I suspect for other App Store publishers, so I would like to ask for a supported way to opt out rather than keep patching it locally.

### Why it matters

App Store Review Guideline **2.5.1** is about *use* of private API and carries no obfuscation carve-out. Separately, the Apple Developer PLA distinguishes plain private-API use (§11.2(a), a curable breach with a 30-day cure period) from **"hiding or trying to hide functionality from Apple's review"** (§11.2(g), which is not). The base64 encoding is what moves this from the first category toward the second, and it was introduced upstream of here — `SDWebImageSVGCoder`'s equivalent change is titled *"Change to hidden the symbols and follows App Store Submit rule"*.

To be clear about what we did and did not find: we have **no evidence of any rejection** caused by this library, and there is a good deal of precedent for the obfuscated form passing review (`expo-image` ships the same construction transitively, at scale, and has for years). Our concern is not the likely case — it is that the unlikely case is not a resubmit.

It also cannot be avoided by configuration today. Choosing SF Symbols stops the private functions being *called*, but `canDecodeImageData:` is invoked for every image the app decodes, and `+[CoreSVGWrapper isSVGData:]` runs `+initialize` and all five `dlsym` lookups on first use. The symbols are in the binary either way.

### What we are asking for

Either would fully solve it, and the first is a one-line change:

1. **`s.exclude_files = "ios/SVG/**/*"` in the podspec by default**, with an opt-in (subspec, or a `$RNBottomTabsEnableSVG` Podfile flag) for the apps that actually want SVG tab icons.
2. **An opt-in flag for the whole SVG decoder**, covering both the sources and the `codegenConfig.ios.modulesConformingToProtocol` registration.

Our reading is that most consumers do not use the SVG path at all, so defaulting it off costs those users nothing and removes the question from their review submission entirely.

### What we are doing meanwhile

Carrying a `patch-package` patch against `1.4.0` that deletes `ios/SVG/{CoreSVG,SvgDecoder}.{h,mm}` and removes the `modulesConformingToProtocol` entry. Verified on RN 0.84 with the new architecture: `pod install` produces an identical pod count, the app builds, the generated `imageDataDecoderClassNames` array is empty, and a string scan of the linked binary finds zero occurrences of `CoreSVGWrapper`, `SvgDecoder`, `CGSVGDocument`, `_imageWithCGSVGDocument` or the base64 literals (with unrelated symbols from the same library present in the same image as controls). Nothing broke — the decoder only ever served SVG bytes handed to RN's image loader.

Happy to send this as a PR if the maintainers would like it in either shape.

### Environment

- `react-native-bottom-tabs@1.4.0`, `@bottom-tabs/react-navigation@1.4.0`
- React Native 0.84, new architecture enabled, iOS, CocoaPods, Xcode 26.6