You can low-pass filter an accelerometer signal. The gravity vector is at DC. Using a 2-axis accelerometer like the Analog Devices ADXL202 should be sufficient for a plane.
Here's an excellent article on all the math.
what happens if the user suddendly moves the plate forward?
You are confusing the concept of translation (change in position) with attitude (orientation). If the plate moves suddenly forward (pure translation) then you, ideally, want to see no change in the output (the attitude didn't change).
If the user suddenly tilts the plate forwards then after an infinite time period the DC value will also correctly and exclusively reflect this change.
An accelerometer measures acceleration. Acceleration is caused by force. Gravity is a force. Gravity is based on mass relationships, separation distance, and the angle between the vectors. Since neither the plate's mass or the Earth's mass is changing, the separation distance is (for all intents and purposes unchanging), for a specific angle (tilt) gravity is a constant force. Things that are constant have 0 frequency (e.g. "DC").
Any given tilt angle will correspond to one (and only one) force vector on the plate through 180 deg.

The problem in a practical system is that you can't wait an infinite amount of time to notice that the attitude has changed. So you must, like everything in engineering, compromise between the requirements. That is why I suggested the approach of a low-pass filter. Where you corner the filter will determine the trade-off between selectivity and accuracy (in the short term).
In practical systems you can corner somewhere around 10Hz and usually do ok (most cell phones take this approach).
link you provide assumes a three axis accelerometer
The third axis is only absolutely required if you need to detect yaw (via gyro) or disambiguate attitude through both hemispheres (via accelerometer), which the original question seems to explicitly discount as undesired motion. If that assumption on my part is in error, the OP can use a 3-axis accelerometer or 2-axis + 1 axis gyro as desired. That is why I said "should be sufficient."
I'd go with a gyro...
If you are trying to minimize cost/power, then using a gyroscope by itself is a poor choice with respect to the accelerometer as proposed. In the tilt sensing application you described, the gyro develops a tilt error that continues to increase without bound as it measures only rotational accelerations, which you must integrate to find the position (tilt).
When you tilt the gyro you'll see a change in the output voltage, but it quickly returns to it's resting level if the new attitude (tilt) is held. This leads to two undesirable problems:
- It becomes extremely sensitive to jostling (shaking and other transient disturbances)
- Error accumulates very quickly and must therefore be "reset" to some known value every so often by correlating it with some other data source (such as the accelerometer as proposed).
Here is data from an experiment conducted by David Anderson on his self-balancing robot:

Note how the error (difference between the blue line and red line) quickly runs away from the ground-truth.
In contrast, the accelerometer measures tilt directly so error does not accumulate. In the gyro, each estimate of tilt is a function of all prior measurements (error accumulates). In the accelerometer, each estimate of tilt is based on only the current reading (to the first order).
You are not going to be able to distinguish potholes clearly from other short peak events apart from being able to distinguish between a rising bump in the road and a hole (the intial direction will be opposite) but you can certainly capture them quite easily.
Determine an initial direction (e.g. negative/positive XYZ depending on how your device is mounted), a threshold level, and a maximum time the reading should be over this level (determined by width of pothole) Then time the peak height/width and see if it fits your pothole characteristic.
The device already contains an internal 1kHz LPF, so you could add a HPF of say 50-200Hz for the potholes, since they will have a fast risetime. I'm not an expert on car vibration frequencies, but you will probably get some noise from vibration however you filter. However that's not an issue as long as the pot hole event is large in comparison with the noise - it looks like the data is okay as it is, I would just sample a bit faster to prevent aliasing (e.g. >2kHz) or add a LPF to the existing internal one as described in the datasheet. Since you are trying to capture fast risetime events, I'd go with the former (faster sampling, possibly with HPF)
To compensate for a change in inclination, you can have a running average value which can be used to zero the axis out (one for each axis). Also, note that a HPF will ignore the DC level, so (as long as it doesn't go off the end of the scale) a slow gradient will make no difference.
According to the datasheet (bottom of page 7 in the link above), the formula for the external capacitance is:
\$ C2 = C3 = C4 = \dfrac{4.97 \times 10^{-6}}{f_{BW}} \$
so your calculation of:
\$ \dfrac{4.97 \times 10^{-6}}{10Hz} = 497nF \$ is correct.
Best Answer
You could use either a magnetometer, or a gyro to detect rotation around an axis parallel to the Earths surface.
If you offset an accelerometer from rotation axis, you could get some information to estimate a rotation angle, but it would be quite hard to do adequately (depending on how good it needs to be), and inferior to the other two sensor types.
I strongly recommend watching Sensor Fusion a google tech talk by InvenSense.
Among many things, it explains how to do what you describe.
There are some issues with sensors for only one of the phenomena (e.g. only magnetometer, or only gyro) for example drift from integrating gyro's. So "Sensor Fusion" is an approach, using a set of algorithms which derive better results by using values from different types of sensors together.
You don't need to buy an InvenSense sensor, though they are pretty low-cost on 'sales' web sites, often from China. Other companies make comparable devices, and there Open Source algorithms on the web.