[Improvement]: Integrate a subset of semtypes into jBallerina runtime

[lochana-chathura]

Description

$subject.

[heshanpadmasiri]

This is to be done similar to #41066 (ie. initially we will support a state where part of the type is still a BType and rest is SemType). For this I have considered 2 approaches,

1. At runtime split a given BType to a SemType component as well as a BType component and type check them separately.
2. Make the SemType the "top level" type and make the BType another sub type data.

First approach is not removing any of the BTypes and instead we are creating additional SemTypes (and extra BType for the BType component). This means we have a performance overhead (in nBallerina I measured ~15% slowdown mainly due to extra instance creation). Second approach should not have that weakness since we are replacing BTypes with SemTypes. Currently I am exploring this approach.

[heshanpadmasiri]

I am planning to convert runtime type representation to SemTypes in fallowing stages

• Convert the runtime representation of nil, int, boolean, string, float, decimal, handle, never and their sub types to use SemTypes.
• Convert the runtime representation of list, map and xml types to SemTypes.

At any stage unions and intersections will represent the parts that are supported under that stage as SemTypes as well. Note that list, map and xml types will require porting the cell types (used to represent mutability) as well. Also note all other types such as table are represented using combinations of above types.

Ballerina Type	Underlying SemType
table	list + mapping
error, object	map
function	list

[heshanpadmasiri]

This is to be done similar to #41066 (ie. initially we will support a state where part of the type is still a BType and rest is SemType). For this I have considered 2 approaches,

1. At runtime split a given `BType` to a `SemType` component as well as a `BType` component and type check them separately.

2. Make the` SemType` the "top level" type and make the `BType` another sub type data.

First approach is not removing any of the BTypes and instead we are creating additional SemTypes (and extra BType for the BType component). This means we have a performance overhead (in nBallerina I measured ~15% slowdown mainly due to extra instance creation). Second approach should not have that weakness since we are replacing BTypes with SemTypes. Currently I am exploring this approach.

Extension of option 2 is to make existing BTypes extends SemType. Basically for each type supported by the runtime API their corresponding implementations will implement both the SemType as well as that interface. Type operations are still immutable and still result in new Semtypes that will only implement the base Type interface. But this will allow things like standard library to continue using (most of) the types as is with minimum modifications. Internally these new types will just become adapters between semtype API and current type APIs

[lochana-chathura]

Closing with #43279