There are multiple ways to do this.
The other ASes could be sending a default route, or the router in AS100 could just have a default route configured.
The other ASes could just advertise their own routes through BGP.
The other ASes could advertise full BGP routes to AS100.
BGP has many factors which could play into the decision of which way to switch traffic destined to another AS. This is the subject of entire books, and it is beyond the scope of this site. It is far more complicated than IGP routing protocols, and it may involve many steps to determine the best path. Often is just boils down to how many AS hops away it is to get to the other AS.
You may be confused about the role of iBGP. The distinction of iBGP and eBGP is whether or not the neighbor is in the same AS. An AS will almost always have more routers than just the routers connecting to other ASes. The routers internal to the AS would have the same AS number as their neighbors, so they would use iBGP.
It would also be a huge discussion about how design within an AS. Again, you could have default routes, full or partial routing tables, a combination, etc., or a mix of IGP and iBGP (which is involved because you could use a full-mesh, route reflectors, confederations, etc.).
What BGP neighbors send each other can be controlled. It could be full routing tables, or it could be whatever the AS owner decides is appropriate. there is no one answer to this question.
When a packet is received at an SDN switch that doesn't have a rule associated with it, it gets forwarded to the controller. Now, the controller may choose to drop it, or do something special (like log it and then forward). This behavior is key to implementing many Openflow features, like learning switches.
https://github.com/mininet/openflow-tutorial/wiki/Create-a-Learning-Switch
Best Answer
OpenFlow specifically - but also generally applicable to all of SDN - doesn't change anything about how your physical device forwards packets. The hardware is the same, and the pipeline that already existed on that device is unchanged.
What OpenFlow does is move the logic for programming the packet matches and actions from on the device itself (the local firmware), to a process that is running on a different device, which may have a view of more than one network element (and thus may be able to make better decisions with a better view of the world - or not). So, while you may configure network routing at a single controller, the controller is then distributing that information to a lot of devices to do what they have always done - match, modify, and forward packets.