How typical is it that developers do this in your organization?
That would be my guideline - the things you mention can easily be considered "part of the job" in some cases and not in others. Example:
Helping with interviewing - often developers are called on to do "peer reviews" of candidates. That's not unusual, and I wouldn't include it - unless you showed such great judgement and skill at this that you were asked far more often than other developers.
At the same time, if you were given serious ownership over the corporate culture and team building, then the work is becoming much more like a team lead and if you are gunning for a leadership position, saying "took on some of the duties of team leadership and staffing decisions" may be reasonable.
Do include meaningful work at your level:
Setting up development tools is something developers typically do. It's not that you are doing an extra job, it's that you have a small group and someone has to do this. With that said, it's a meaningful project, worth noting with a sentence or bullet in the description of this company or role.
As an aside, particularly with large tools or processes, it's nice to note the scope of people/teams using them. Setting up a source control system for 1 person is different than 5, which is different than 50 people on 8 different teams with different branches, releases, etc.
Attending vs. Contributing or Driving Meetings
"Attending" implies that you are fairly passive. You're there to answer questions, or take notes and figure out the next steps after the deal is closed. If that's the case, I'd skip it.
If, however, you contribute to the presentations, give part of it, and/or are called on for key input or decisions (for example, effort estimates, project risks, etc) - then you are taking on some pretty senior work and it's worth noting that you "contributed" to key proposals relating to obtaining new work.
Again - it's something of a frequency thing - if you're that guy that they can't live without, because you have an awesome understanding of your role and you are very good at describing the work to non-developers, then you want to highlight these awesome add-on skills you have.
But if this is something that everyone does, I'd skip it.
Startup vs. Large Organizations
I'll say that when I look at a resume, I do look at the size of the company and my expectations are somewhat correlated to the company type. A small startup has much wider responsibilities within each role, a large company has more specialization and lack of wider responsiblity may simply mean less opportunity to step up. Having a sense of the size of the company usually gives me an indication on whether the person had to be a jack of all trades and I suit my interview to verifying accordingly in light of what skills I'm looking for.
In focusing on the resume - I want to see what work you did, and what you want to do. If you didn't like doing some of these things - skip them. And if the ancillary tasks take precious real estate away from the reviewer reading about your core work - skip 'em.
I happened to read a resume today that as presented spanned at least 3 pages. I say "at least" because I really didn't get past page 2. The first page was a very long list of bullets of all the soft qualities that were great about the candidate, then a 3-5 line set of technologies he'd worked with, then a 1/2+ page of job experience that spanned 5+ years, then more pages with more experience. I read 3 opening bullets, the technology list, and the descriptions of work on the previous job. By that point, I had made my decision and I had run out of time to read, learn and think about it.
In deciding what extra stuff to put in the resume, keep in mind a manager like myself. I have 10-20 minutes to read your resume and get something out of it. Make sure that what I get is what you want me to get. If you want a solid developer job, make your resume be about that. If you want a team lead, project proposal, dev environment building job - make your resume be about that.