There isn't enough information to say for sure what the best approach will be in your particular case, but there are some general approaches to designing relational schemas that lead to the comments below.
I don't like your option 2, because I've seen people get into an awful mess with that approach. It makes it much easier to write bugs than ether option 1 or option 3, and that alone would incline me to reject it. It certainly isn't relational, and it can lead to unpleasantly complex queries with poor performance.
I guess the ability to declare a table "sparse" may make option 1 reasonable, but personally I would probably prefer prefer option 3 if there are a large number of columns involved. A lot of people are dogmatically against any use of nullable columns, but in my view there are cases where they are justifiable, so I wouldn't rule option 1 out altogether, but I do feel that nulls should be avoided unless there is a very good justification for them and I don't see one here on the information you have provided (I also don't see that there is definitely no such justification).
There is a fourth option: instead of a parent table, make each country-specific table have the columns that would be in the parent table as well as the country-specific columns, and have a view which is the union of the restrictions of the country-specific tables to the "parent" columns (one of which is a country identifier, and is constant within each country-specific table). As that view is updateable without requiring a trigger, you can do anything with that view that you could have done with a parent table without accessing a country table, and you avoid the joins that would have been needed to get the complete picture for individual countries; the downside is that the working set for country-independent working may be larger that it would with a parent table; that of course can be eliminated by indexing the view, but that creates a disc space overhead.
To choose between the 3rd option and the two variants of the fourth option requires an exercise in performance evaluation (covering disc storage space, RAM storage space, IO volume, and CPU usage); but I believe that with any of these three you are probably going to have less complex code than with either of your first two options.