Is it better to make such rather simple design decisions up front,
even there is no need in the current situation, or do we have to
change a lot in the later progress of the project?
Delay architectural decisions until as late as possible (but no later). You are going to know more about the problem in the future than you do right now, and thereby likely come up with smarter decisions.
For instance, imagine you are trying to decide up front whether to use MongoDB, some other NoSQL or traditional SQL for a project. Delay the decision: write a simple repository layer that will simply save the data in memory, or save data to a JSON file for now, and continue on. Eventually you'll have to replace this stub with something - but later on, you might know with more of a certainty which way to go: "hey, all of this really is a great fit for a document store" or "you know, SQL transactions would really help".
Its important to do this in conjunction with the concept of prioritizing the riskiest parts of your application to be developed first - that is, the parts you understand the least you should do before you do other work. This should mean you end up with an architecture that fits your solution, instead of forcing your solution later to fit in to your pre-selected architecture.
I don't mean to suggest that every project start with an exhaustive comparison of every possible web framework, storage technology, and so on. Hopefully in most projects you can simply default to reliable frameworks that have been used in the past under guidance from the team architect. I'm suggesting that this technique of delaying architectural decisions should be used when you are faced with a decision to which you don't know the answer.
One way to look at it - in an Agile project, you're always doing architecture, instead of trying to do the architecture "up front". If a pair of programmers (you are pair programming right?) picks up a story and realizes that it requires an architectural discussion, they should have it. If they feel they should involve more devs, then they should do that. If this results in a desire to remove some technical debt caused by previous lack of architecture or previous poor architectural decisions, what we've done is had the devs write up a work item for this and work with the product owner to schedule it in. Generally, explaining it in terms of ROI: "we believe the removal of this technical debt will result in the following return", generally in terms of faster response times, or shorter future development cycles.
Also, as a commenter pointed out:
The project we are developing is a framework for future projects and
will be reused many times in the next years.
This does not sound agile at all. Are you sure your business requirements demand this sort of thing? Agile is all about recognizing that change happens - this week's great idea is next week's "bottom of the backlog". What technique in future prediction is leading you to be certain about what things will be important to you in three months, much less 'the next few years'?
As far as the original question "who should be the architect in an agile project", I've always selected the most experienced programmer on the team or the programmer that knows the code base the best, and given them the architect title. Sometimes the architect is just letting the developers come up with a solution and guiding the process a little bit, sometimes they are making the call. In teams organized this way, the architect is contributing code to the project most of the time, and playing the "architect" role whenever required.