Improve SDK Type Inference in SDK Automation

[wanlwanl]

Fix: #9520
Problem: Service team doesn't set isModularClientLibrary explicitly, we can improve user experience by inferencing sdk type automatically
Solution: add the Inference flow below

if (generateByTypeSpec) {
    if (isModularLibrary !== undefined) return options.isModularLibrary ? isModular : isRLC;
    if (flavor === "azure") {
        if (namespace.includes("Management")) { // MPG
            return isModular; // by default
        } else return isRLC; // DPG
    } else { // unbranded
        return isModular; // by default
    }
} else { // generate by autorest
    // original behavior
    if (hasIsRestLevelClientOption) return isRLC;
    return isHLC;
}

[MaryGao]

I was wondering if we still need this, we already adopted default behavior(but not released yet) in codegen side: Azure/autorest.typescript#2973.

[wanlwanl]

If so, we don't need to check it.
However, we have an independent changelog generation tool. GetSDKType() will be used to bump version - need to find api-version type (stable or preview) based on different client type. I'm wondering if codegen side can add 'api-version' into package.json or somewhere else, then I don't need the check of 'management' any more.

[MaryGao]

Maybe we could directly refer the package name: https://github.com/Azure/azure-rest-api-specs/blob/main/specification/contosowidgetmanager/Contoso.Management/tspconfig.yaml#L39.

Starting with @azure would be Modular and starting with @azure-rest would be RLC.

I'm wondering if codegen side can add 'api-version' into package.json or somewhere else

I may not get your point, the api-version is the package version or spec version? We have an issue to list all service apiVersion in README: Azure/autorest.typescript#2588.